[RFC/PATCH 0/2] Use FS_IOC_SYNCFS to speed up unpack
Hi again,
Guillem Jover wrote:
> On Sat, 2010-11-27 at 01:41:19 -0600, Jonathan Nieder wrote:
>> I don't really understand this point of view: isn't the fsync storm
>> going to cause seeky I/O on just about all file systems?
>
> Well sure it might, but then some seem to be able to cope just fine, even
> ext4 with nodelalloc.
Ok, here's something to test with.
Patch 1 removes the "synchronous sync(2)" codepath, since patch 2
would be better in almost every way.
Patch 2 introduces a --sync-per-filesystem flag to try out the
new ioctl. It defaults to false, and when set, causes the ioctl
to be used to sync each filesystem once rather than an fsync per
file. If the ioctl fails[2], the code falls back to fsync[3]. For
this patch to have a more noticeable effect, a kernel with
http://thread.gmane.org/gmane.linux.file-systems/44628 applied is
needed.
A peek at the result[1]:
user system actual %CPU
--sync-per-filesystem 3.40 1.35 9.78 48
usual fsync method 3.50 1.44 31.54 15
Thoughts? Improvements? Benchmarks?
Jonathan Nieder (2):
Remove --enable-sync-sync codepath
Add new --sync-per-filesystem to use FS_IOC_SYNCFS on unpack
configure.ac | 3 +-
debian/changelog | 4 ++
m4/dpkg-funcs.m4 | 28 ---------------
man/dpkg.1 | 7 ++++
src/archives.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++-----
src/main.c | 4 ++-
src/main.h | 2 +-
7 files changed, 105 insertions(+), 41 deletions(-)
[1] cold cache, best-of-three, from dpkg -i /var/cache/apt/archives/python2.7*
[2] an evil hack would be to fall back to mount -o remount or BLKFLSBUF.
I'm not interested in doing that, though.
[3] probably should be changed to error out instead of falling back for errors
other than ENOTSUP.
Reply to: