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

Reply via email to