[Rpm-maint] [rpm-software-management/rpm] RFE: Offer LMDB as an alternative engine to BDB for rpmdb (#128)

[Per Øyvind Karlsen]

2017-01-26 23:43 GMT+01:00 Per Øyvind Karlsen <proyvind at moondrake.org>:

> 2017-01-16 8:04 GMT+01:00 Panu Matilainen <pmatilai at laiskiainen.org>:
>
>> On 01/16/2017 02:51 AM, Neal Gompa wrote:
>>
>>> On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius <rc040203 at freenet.de>
>>> wrote:
>>>
>>>> On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
>>>>
>>>> I'm not sure how true it is, but it seems to bear out with the number of
>>>>> previously BDB users now being LMDB users.
>>>>>
>>>>
>>>>
>>>> Unless a different DB offers substantial advantages over BDB to RPM,
>>>> which
>>>> does not endanger or destabilize rpm, I do not see any reason to switch
>>>> different DB.
>>>>
>>>>
>>> BDB 5 isLook unmaintained. There's no one upstream working on it, since
>>> Oracle has moved onto BDB 6. No one wants to use BDB 6. RPM should not
>>> depend on dead software. And there are significant performance
>>> advantages to LMDB, according to various benchmarks[1].And LMDB looks
>>> like it could enable making the RPMDB to be more resilient[2].
>>>
>>> [1]: https://symas.com/products/lightning-memory-mapped-database/
>>> project-benchmarks/
>>> [2]: https://symas.com/products/lightning-memory-mapped-database/
>>> feature-comparison/
>>>
>>>
>> Lies, statistics, benchmarks, vendor benchmarks... ditto with feature
>> comparisons.
>>
> That's rather quite controversial claims, care to back them up with some
> references?
>
> tyself persponally, I wasn't unable to find anything suggesting what you
> claim, I would've expected to find there being any discussion on the
> wikipedia article about it in such case:
> https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database
>
Looking at feature of lmdb, wouldn't it be possible provide more reliable
rollback support without ie. nofsync use wreaking enitre havoc to
transactions and rpmdb?

Database matters are really the subject which I admit the last amount of
insight on related to rpm, but previously rpm's --rollback support was
yanked with claims of never working right and more reliable support anyways
being superiorly addressed on filesystem level togh ie. btrfs snapshot
support, for which AFAIK no support of has even been implemented in higher
levels tools as back then suggested and serving for rationale of it's
removal.

While I know of debian implementing btrfs snapshot support in apt, to my
understanding it was never actually implemented in any higher level tools,
making matters worse, with ie. Fedora even since making xfs their fs of
choice, obvious practical difficultues and explainings of why never having
been realized arises easily..

For never having "worked properly", it was working quite well with quite
common usage of the urpmi.recover tool offered in mandriva linux
implementing  rpm's rollback support, with usage of having been quite
common without any known major issues reported against suggesting not
working properly enough nor not meeting satisfactory expectations wrt.
reliability and functionallity provided.

After adopting rpm5.org in cooker, urpmi.recover was revived, with other
professional developers deeming it sufficiently satisfying their usage of,
with some further new development work taking place, while also work on
reintegrating the revived tool of taking place.

To my understanding lmdb's copy on write semantics should prevent
transaction data not written to disk to risk making rpmdb very prone to
corruptions by ie. nofsync use with only major reliability concern of being
whether transaction logs properly written to disk for which rollback up to
the point of is major cause of concern to my understanding..
Transatction logs not written to disk is AFAIK not something which not even
btrfs is being any more immune to implications of than as for anywhere else
in general...

Well. just some thougts on the matter based on my (lack of) understanding,
any answers explaining the why's and why not's on the matter would be
appreciated. :)

--
Regards,
Per Øyvind
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170128/626b6ca2/attachment.html>