On Mon, 2010-11-15 at 19:31 +0100, Philipp Kern wrote: > Dear kernel team, > > On Mon, Nov 15, 2010 at 09:58:47AM +0100, Sven Joachim wrote: > > > I'm sorry, I won't have the time to do new benchmarks on this. > > > > > > The only benchmarks we have have been made by Sven Joachim: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20 > > > (asyncsync is the switch to sync() instead of fsync() so the opposite of > > > the above patch) > > > > > > He mentionned that without the sync() trick it takes 3 to 5 times longer > > > to unpack a package. > > > > Even longer actually, see the figures below. > > > > > Sven, would you have time to provide some of the stats asked by the > > > release team? > > > > I can only test ext4, here are some samples of dpkg unpacking a large > > package (dpkg --unpack --no-triggers emacs23-common_23.2+1-5.1_all.deb), > > leaving out user and sys times since those do not vary much (~ 0.5 > > seconds in every case): > > > > dpkg version Cache mount options unpack time > > ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ > > 1.15.8.5 cold defaults 7.803s > > 1.15.8.5 warm defaults 5.283s > > 1.15.8.5 cold nodelalloc 7.608s > > 1.15.8.5 warm nodelalloc 3.783s > > 1.15.7 cold defaults 40.429s > > 1.15.7 warm defaults 37.848s > > 1.15.7 cold nodelalloc 7.945s > > 1.15.7 warm nodelalloc 3.524s > > > > All this is with a standard squeeze kernel on an otherwise idle system. > > It should be noted that with lots of other disk activity such as writing > > to USB disks, the figures in dpkg 1.15.8.5 can become much worse and > > dpkg might even stall because of the many sync() calls: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595927. > > > > As far as ext4 is concerned, switching back to fsync() seems to be > > acceptable only if the filesystem is mounted with the nodelalloc > > option. Maybe the installer should set this up. > > and I don't suppose we could make that the default? Is there anything > else the dpkg developers can try to be portable and still not be > sacrificing performance? I'm coming to this late. It sounds like dpkg has changed its behaviour several times recently. Please can you summarise dpkg's current and proposed use of fsync() vs sync(), and the reasons for this. Also do I understand correctly that fsync() is more expensive when ext4 delayed allocation is in use? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part