Hi!
I've done a couple of performance measurements around the rpmdb. It
turns out that the huge number of f(data)sync calls is significantly
slowing down RPM on todays ext[234] file systems.
Setting no_fsync in the rpmdb config drops the F10 Everything install
--justdb from 2:51:00 to 4:50.
On Tue, Aug 11, 2009 at 12:19 PM, Florian Festiffe...@redhat.com wrote:
Hi!
I've done a couple of performance measurements around the rpmdb. It turns
out that the huge number of f(data)sync calls is significantly slowing
down
RPM on todays ext[234] file systems.
Setting no_fsync in the
On 08/11/2009 12:47 PM, devzero2000 wrote:
On Tue, Aug 11, 2009 at 12:19 PM, Florian Festiffe...@redhat.com
mailto:ffe...@redhat.com wrote:
Any thoughts or safety concerns?
Beware of data loss with ext4 dropping down fsync
On Tue, Aug 11, 2009 at 1:33 PM, Florian Festiffe...@redhat.com wrote:
On 08/11/2009 12:47 PM, devzero2000 wrote:
On Tue, Aug 11, 2009 at 12:19 PM, Florian Festiffe...@redhat.com
mailto:ffe...@redhat.com wrote:
Any thoughts or safety concerns?
Beware of data loss with ext4 dropping down
Hi!
Very difficult to recover from a zero byte RPMDB Packages file, i
think. Overall there is, as always, a tradeoff between performance and
integrity.
Even with this patch fsync is always called after writes to the
Packages file (in opposite to adding nofync to the rpmdb configuration