Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   disabling syncs ( was: suite wide config options? ) (http://www.linux-archive.org/debian-dpkg/593687-disabling-syncs-suite-wide-config-options.html)

Phillip Susi 11-02-2011 02:41 AM

disabling syncs ( was: suite wide config options? )
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/01/2011 10:50 PM, Guillem Jover wrote:
> 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...

Why should they use a third party LD_PRELOAD library ( which sudo
disables ) to make dpkg usable? What does keeping it out of dpkg gain?

> 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?).

While the performance of syncs on btrfs is horrid and should be
improved, there is nothing sane about continuing to use them when you
know they are entirely pointless. Even on ext4 disabling the syncs
offers a 600% speed up, and if you have a system snapshot that the
boot loader can easily roll back to if the upgrade does not complete
correctly, then all of these database syncs are a complete waste of time.

On a traditional filesystem, going to some length to ensure the system
will still boot after a crash is perfectly reasonable, but in the
presence of snapshots, such effort is entirely wasted, regardless of
whether it is a 600% or a 120,000% performance penalty.

Even if btrfs is eventually improved to to be just as fast as ext4 in
this regard, why should users be forced to suffer through a two hour
long dist-upgrade when it could be done in 20 minutes, and still be safe?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6wu/0ACgkQJ4UciIs+XuI5UwCgj5lWmPVY9R/BfkWrqikjqOzs
aCMAoLuYId51mmQX8ApJOUZoGlNFyGZe
=o2W+
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EB0BC01.5090105@cfl.rr.com">http://lists.debian.org/4EB0BC01.5090105@cfl.rr.com

Jonathan Nieder 11-02-2011 02:58 AM

disabling syncs ( was: suite wide config options? )
 
Phillip Susi wrote:

> What does keeping it out of dpkg gain?

Maintainability. Running "eatmydata dpkg -i <foo>.deb" disables
fsyncs in maintainer scripts, too, which might match the desired
behavior better. (On the other hand, if you only want to suppress
fsync()s in admindir, perhaps because you keep it on a different
filesystem, then you'd need a finer-tuned interface than either
"dpkg --force-something" or eatmydata can provide. When that
happens, it's probably best to implement it once in eatmydata,
where the logic can be reused by other apps, too.)

No strong opinion from me about what's the right choice in this
particular case, though.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111102035839.GC24526@elie.hsd1.il.comcast.net">h ttp://lists.debian.org/20111102035839.GC24526@elie.hsd1.il.comcast.net

Andrew Stormont 11-02-2011 12:44 PM

disabling syncs ( was: suite wide config options? )
 
Hi,

+1 for adding support for libeatmydata, preferably as an option that could
be enabled in /etc/dpkg/dpkg.cfg.
It would be a nice feature to have for those of us that keep our rootfs on
a ZFS volume.

Thanks,
Andy



On 02/11/2011 03:58, "Jonathan Nieder" <jrnieder@gmail.com> wrote:

>Phillip Susi wrote:
>
>> What does keeping it out of dpkg gain?
>
>Maintainability. Running "eatmydata dpkg -i <foo>.deb" disables
>fsyncs in maintainer scripts, too, which might match the desired
>behavior better. (On the other hand, if you only want to suppress
>fsync()s in admindir, perhaps because you keep it on a different
>filesystem, then you'd need a finer-tuned interface than either
>"dpkg --force-something" or eatmydata can provide. When that
>happens, it's probably best to implement it once in eatmydata,
>where the logic can be reused by other apps, too.)
>
>No strong opinion from me about what's the right choice in this
>particular case, though.
>
>
>--
>To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmaster@lists.debian.org
>Archive:
>http://lists.debian.org/20111102035839.GC24526@elie.hsd1.il.comcast.net
>



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAD6F964.2813B%andyjstormont@gmail.com">http://lists.debian.org/CAD6F964.2813B%andyjstormont@gmail.com


All times are GMT. The time now is 02:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.