[Rpm-maint] [PATCH] RPMDB Performance

devzero2000 pinto.elia at gmail.com
Tue Aug 11 12:20:03 UTC 2009


On Tue, Aug 11, 2009 at 1:33 PM, Florian Festi<ffesti at redhat.com> wrote:
> On 08/11/2009 12:47 PM, devzero2000 wrote:
>>
>> On Tue, Aug 11, 2009 at 12:19 PM, Florian Festi<ffesti at redhat.com
>> <mailto:ffesti at redhat.com>> wrote:
>> > Any thoughts or safety concerns?
>> Beware of data loss with ext4 dropping down fsync
>>
>>
http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892
>> The problem with ext4, XFS, or another extent-based filesystem is
inherent
>> in their design, afaik.
>>
> As far as I understand the described problem does not directly affect this
> patch as there is no "rename" done. Of course dropping the fsyncs for the
> indexes may lead to a corruption of the indexes and the db environment.
But
> both can be recovered as described on
> http://www.rpm.org/wiki/Docs/RpmRecovery.

Teo described the real problem here (
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45).
So some files can be reset to zero byte after a crash and, in a desktop or
mobile, this probability can be  very high, many users turn off the pc and
stop or suffer a power loss.It is true that Teo has recently introduced an
mount option  which is similar to the effect of data = ordered in ext3 but
it seems to me far too recent to be able to make an assessment. Very
difficult to recover from a zero  byte RPMDB Packages file, i think. Overall
there is, as always, a tradeoff between performance and integrity.

Regards

>Omitting the fsyncs can also just
> lead to additional damage if there is a power loss or any other hard
> disruption of the OS. So the risk is comparably limited if I didn't miss
> something else.
>
> Florian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20090811/9426e2cc/attachment.htm>


More information about the Rpm-maint mailing list