Hi, On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote: > I'd like to apply two patches for the next dpkg 1.15.8.6 upload. And > would like to run them through you to avoid having to possibly revert > them from dpkg's sid git branch. > > Those are related to the fsync()/sync() changes in dpkg from some time > ago, the patches would: > > 1) Switch back from sync() to fsync() before rename() (while keeping > the sync() code around for the benefit of other distributions > that might not want to switch just yet). So to avoid unrelated > I/O when there's background work being done for example. This > hack also only works on Linux where sync() is synchronous, so > it would unify that code path for all dpkg supported platforms. > > Bug: #588339 > > <http://git.hadrons.org/?p=debian/dpkg/dpkg.git;a=commitdiff;h=87740373> I do have to say that I'm not overly happy about this change this late in the freeze. I suppose this resembles what we currently have in Lenny? What are the implications for ext4 and btrfs? Why was it changed in the first place? > 2) Add a new --force-unsafe-io to disable those fsync() for people > using certain file systems where the only option is to choose > between reliability or acceptable performance. Or in cases where > the data is cached and it might not be important to lose it. > > Bug: #584254 > > <http://git.hadrons.org/?p=debian/dpkg/dpkg.git;a=commitdiff;h=0484cd7d> So even when you don't do sync() anymore you still want to disable those fsyncs()? Granted, it's a self-contained new feature. What's the use case for squeeze? d-i I heared, but I'm not sure that they'd use it in this cycle. And tmpfs users, or who? Kind regards, Philipp Kern
Attachment:
signature.asc
Description: Digital signature