Re: suite wide config options?

[Guillem Jover <guillem@debian.org>]

On Tue, 2011-11-01 at 21:44:31 -0400, Phillip Susi wrote:
> On 11/01/2011 09:30 PM, Guillem Jover wrote:
> > Yes, only dpkg and dselect read configuration files. But then what
> > would that option be? The only commonish one is admindir.
> 
> I'm adding an option to disable all fsync() family calls.  Initially I
> added it as a --force-no-syncs option to dpkg, but then realized that
> there are many syncs in the lib section used by the other binaries as
> well, so they need a way to enable the option.  How about an
> environment variable?  This may fit in well with apt anyhow, as it can
> set the variable if it was able to make a btrfs snapshot before it
> starts running dpkg et al.

As said before countless times (I think there's even a wontfix bug
report), I don't want to see an option that disables syncs on the
database, which has always performed them. There's so much rope I'm
willing to give to the user. If the user does not value their data,
or they are using a throw-away filesystem, then yes, kindly use
something like libeatmydata, or use a saner filesystem...

> My preliminary testing shows some impressive results.  Comparing ext4,
> btrfs, stock dpkg, dpkg run with --force-unsafe-io ( set in dpkg.cfg )
> dpkg run with libeatmydata, and dpkg with my --force-no-syncs patch so
> far, I get the following times for Ubuntu 11.10 install and then
> upgrade ( after separate download ):
> 
> Stock:
>   Ext4:   6m23s / 6m46s
>   btrfs:  13m43s / gave up
> 
> - --force-unsafe-io:
>   Ext4:   ( didn't bother )
>   btrfs:  9m20s / 142m

For the btrfs case, it seems like there's something to fix in the
filesystem implementation, those numbers are atrocious. In addition
(something I've mentioned before too), if btrfs does not currently
have it, it should get sync_file_range() support. In any case the
current situation on btrfs means that fsync() is otherwise completely
unusable (when the filesystem makes it necessary?).

regards,
guillem