FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 11-08-2010, 02:40 PM
Phillip Susi
 
Default Pre-approval request for dpkg sync() changes for squeeze

On 11/6/2010 5:41 AM, Sven Joachim wrote:
> For ext4, mounting with the nodelalloc option helps a lot, although this
> option allegedly slows down ext4 in the general case.

How does that help? Doesn't it just disable the delayed allocator,
forcing the blocks to be allocated when they hit the cache, rather than
when flushed? Wouldn't that make sure you don't get zero byte files,
but instead get files full of trash?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CD819EF.5070702@cfl.rr.com">http://lists.debian.org/4CD819EF.5070702@cfl.rr.com
 
Old 11-08-2010, 02:50 PM
Sven Joachim
 
Default Pre-approval request for dpkg sync() changes for squeeze

On 2010-11-08 16:40 +0100, Phillip Susi wrote:

> On 11/6/2010 5:41 AM, Sven Joachim wrote:
>> For ext4, mounting with the nodelalloc option helps a lot, although this
>> option allegedly slows down ext4 in the general case.
>
> How does that help? Doesn't it just disable the delayed allocator,
> forcing the blocks to be allocated when they hit the cache, rather than
> when flushed? Wouldn't that make sure you don't get zero byte files,
> but instead get files full of trash?

I just meant that fsync() seems to be a lot faster in ext4 with that
mount option, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588339#50. I have no
idea why this is so, though.

Sven


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tyjrhl0t.fsf@turtle.gmx.de">http://lists.debian.org/87tyjrhl0t.fsf@turtle.gmx.de
 
Old 11-09-2010, 05:50 PM
Philipp Kern
 
Default Pre-approval request for dpkg sync() changes for squeeze

Hi,

On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote:
> 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'm still not sure we have all needed information. Would you mind doing
a matrix what this change would cause? I.e. if we get performance
regressions on ext4, btrfs or even ext3 with the squeeze kernel (we're
really only interested in that one, not some random other revision)
or if we even get data safety regressions.

Thanks
Philipp Kern
 
Old 11-10-2010, 07:17 AM
Philipp Kern
 
Default Pre-approval request for dpkg sync() changes for squeeze

On Tue, Nov 09, 2010 at 07:50:23PM +0100, Philipp Kern wrote:
> On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote:
> > 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'm still not sure we have all needed information. Would you mind doing
> a matrix what this change would cause? I.e. if we get performance
> regressions on ext4, btrfs or even ext3 with the squeeze kernel (we're
> really only interested in that one, not some random other revision)
> or if we even get data safety regressions.

I also forgot to throw nfs into the picture.

Kind regards,
Philipp Kern
 
Old 11-15-2010, 06:21 AM
Raphael Hertzog
 
Default Pre-approval request for dpkg sync() changes for squeeze

Hi,

On Wed, 10 Nov 2010, Philipp Kern wrote:
> On Tue, Nov 09, 2010 at 07:50:23PM +0100, Philipp Kern wrote:
> > On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote:
> > > 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'm still not sure we have all needed information. Would you mind doing
> > a matrix what this change would cause? I.e. if we get performance
> > regressions on ext4, btrfs or even ext3 with the squeeze kernel (we're
> > really only interested in that one, not some random other revision)
> > or if we even get data safety regressions.
>
> I also forgot to throw nfs into the picture.

I'm sorry, I won't have the time to do new benchmarks on this.

The only benchmarks we have have been made by Sven Joachim:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20
(asyncsync is the switch to sync() instead of fsync() so the opposite of
the above patch)

He mentionned that without the sync() trick it takes 3 to 5 times longer
to unpack a package.

Sven, would you have time to provide some of the stats asked by the
release team?

We really need to upload dpkg this week so we must take a decision what
goes in.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101115072105.GA6865@rivendell.home.ouaza.com">ht tp://lists.debian.org/20101115072105.GA6865@rivendell.home.ouaza.com
 
Old 11-15-2010, 07:58 AM
Sven Joachim
 
Default Pre-approval request for dpkg sync() changes for squeeze

On 2010-11-15 08:21 +0100, Raphael Hertzog wrote:

> On Wed, 10 Nov 2010, Philipp Kern wrote:
>> On Tue, Nov 09, 2010 at 07:50:23PM +0100, Philipp Kern wrote:
>> > On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote:
>> > > 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'm still not sure we have all needed information. Would you mind doing
>> > a matrix what this change would cause? I.e. if we get performance
>> > regressions on ext4, btrfs or even ext3 with the squeeze kernel (we're
>> > really only interested in that one, not some random other revision)
>> > or if we even get data safety regressions.
>>
>> I also forgot to throw nfs into the picture.
>
> I'm sorry, I won't have the time to do new benchmarks on this.
>
> The only benchmarks we have have been made by Sven Joachim:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20
> (asyncsync is the switch to sync() instead of fsync() so the opposite of
> the above patch)
>
> He mentionned that without the sync() trick it takes 3 to 5 times longer
> to unpack a package.

Even longer actually, see the figures below.

> Sven, would you have time to provide some of the stats asked by the
> release team?

I can only test ext4, here are some samples of dpkg unpacking a large
package (dpkg --unpack --no-triggers emacs23-common_23.2+1-5.1_all.deb),
leaving out user and sys times since those do not vary much (~ 0.5
seconds in every case):

dpkg version Cache mount options unpack time
̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅
1.15.8.5 cold defaults 7.803s
1.15.8.5 warm defaults 5.283s
1.15.8.5 cold nodelalloc 7.608s
1.15.8.5 warm nodelalloc 3.783s
1.15.7 cold defaults 40.429s
1.15.7 warm defaults 37.848s
1.15.7 cold nodelalloc 7.945s
1.15.7 warm nodelalloc 3.524s

All this is with a standard squeeze kernel on an otherwise idle system.
It should be noted that with lots of other disk activity such as writing
to USB disks, the figures in dpkg 1.15.8.5 can become much worse and
dpkg might even stall because of the many sync() calls:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595927.

As far as ext4 is concerned, switching back to fsync() seems to be
acceptable only if the filesystem is mounted with the nodelalloc
option. Maybe the installer should set this up.

Regards,
Sven


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tyjjufnc.fsf@turtle.gmx.de">http://lists.debian.org/87tyjjufnc.fsf@turtle.gmx.de
 
Old 11-15-2010, 05:31 PM
Philipp Kern
 
Default Pre-approval request for dpkg sync() changes for squeeze

Dear kernel team,

On Mon, Nov 15, 2010 at 09:58:47AM +0100, Sven Joachim wrote:
> > I'm sorry, I won't have the time to do new benchmarks on this.
> >
> > The only benchmarks we have have been made by Sven Joachim:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20
> > (asyncsync is the switch to sync() instead of fsync() so the opposite of
> > the above patch)
> >
> > He mentionned that without the sync() trick it takes 3 to 5 times longer
> > to unpack a package.
>
> Even longer actually, see the figures below.
>
> > Sven, would you have time to provide some of the stats asked by the
> > release team?
>
> I can only test ext4, here are some samples of dpkg unpacking a large
> package (dpkg --unpack --no-triggers emacs23-common_23.2+1-5.1_all.deb),
> leaving out user and sys times since those do not vary much (~ 0.5
> seconds in every case):
>
> dpkg version Cache mount options unpack time
> ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅
> 1.15.8.5 cold defaults 7.803s
> 1.15.8.5 warm defaults 5.283s
> 1.15.8.5 cold nodelalloc 7.608s
> 1.15.8.5 warm nodelalloc 3.783s
> 1.15.7 cold defaults 40.429s
> 1.15.7 warm defaults 37.848s
> 1.15.7 cold nodelalloc 7.945s
> 1.15.7 warm nodelalloc 3.524s
>
> All this is with a standard squeeze kernel on an otherwise idle system.
> It should be noted that with lots of other disk activity such as writing
> to USB disks, the figures in dpkg 1.15.8.5 can become much worse and
> dpkg might even stall because of the many sync() calls:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595927.
>
> As far as ext4 is concerned, switching back to fsync() seems to be
> acceptable only if the filesystem is mounted with the nodelalloc
> option. Maybe the installer should set this up.

and I don't suppose we could make that the default? Is there anything
else the dpkg developers can try to be portable and still not be
sacrificing performance?

Kind regards
Philipp Kern
 
Old 11-15-2010, 05:31 PM
Philipp Kern
 
Default Pre-approval request for dpkg sync() changes for squeeze

Dear kernel team,

On Mon, Nov 15, 2010 at 09:58:47AM +0100, Sven Joachim wrote:
> > I'm sorry, I won't have the time to do new benchmarks on this.
> >
> > The only benchmarks we have have been made by Sven Joachim:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20
> > (asyncsync is the switch to sync() instead of fsync() so the opposite of
> > the above patch)
> >
> > He mentionned that without the sync() trick it takes 3 to 5 times longer
> > to unpack a package.
>
> Even longer actually, see the figures below.
>
> > Sven, would you have time to provide some of the stats asked by the
> > release team?
>
> I can only test ext4, here are some samples of dpkg unpacking a large
> package (dpkg --unpack --no-triggers emacs23-common_23.2+1-5.1_all.deb),
> leaving out user and sys times since those do not vary much (~ 0.5
> seconds in every case):
>
> dpkg version Cache mount options unpack time
> ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅
> 1.15.8.5 cold defaults 7.803s
> 1.15.8.5 warm defaults 5.283s
> 1.15.8.5 cold nodelalloc 7.608s
> 1.15.8.5 warm nodelalloc 3.783s
> 1.15.7 cold defaults 40.429s
> 1.15.7 warm defaults 37.848s
> 1.15.7 cold nodelalloc 7.945s
> 1.15.7 warm nodelalloc 3.524s
>
> All this is with a standard squeeze kernel on an otherwise idle system.
> It should be noted that with lots of other disk activity such as writing
> to USB disks, the figures in dpkg 1.15.8.5 can become much worse and
> dpkg might even stall because of the many sync() calls:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595927.
>
> As far as ext4 is concerned, switching back to fsync() seems to be
> acceptable only if the filesystem is mounted with the nodelalloc
> option. Maybe the installer should set this up.

and I don't suppose we could make that the default? Is there anything
else the dpkg developers can try to be portable and still not be
sacrificing performance?

Kind regards
Philipp Kern
 
Old 11-17-2010, 04:08 AM
Guillem Jover
 
Default Pre-approval request for dpkg sync() changes for squeeze

Hi!

On Mon, 2010-11-15 at 08:21:05 +0100, Raphael Hertzog wrote:
> On Wed, 10 Nov 2010, Philipp Kern wrote:
> > On Tue, Nov 09, 2010 at 07:50:23PM +0100, Philipp Kern wrote:
> > > On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote:
> > > > 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'm still not sure we have all needed information. Would you mind doing
> > > a matrix what this change would cause? I.e. if we get performance
> > > regressions on ext4, btrfs or even ext3 with the squeeze kernel (we're
> > > really only interested in that one, not some random other revision)
> > > or if we even get data safety regressions.
> >
> > I also forgot to throw nfs into the picture.

I think I provided all relevant information in this thread. Anyway a
short summary regarding performance would be:

* ext3 does not have significant difference with either sync() or
fsync().
* ext4 performs slower with fsync() + mount defaults than sync() +
mount defaults, should do as ext3 with either fsync() or sync()
with nodelalloc.
* btrfs should perform slower using sync() than fsync() (as I understood
from Modestas Vainius and Mike Hommey comments, I've not seen actual
benchmark results checking each against the other though).

And regarding data safety:

* ext3 should not lose data even w/o sync() or fsync(), at most the
status db will get out of sync relative to what's extracted on disk.
* ext4 *will* get zero-length files w/o sync() or fsync() in dpkg, but
*will* also get those with any other software not doing the syncs
(i.e. most stuff in Debian) with default mount options anyway. So
ext4 by default is not safe against data loss. nodelalloc should
supposedly fix that.
* btrfs, I don't really know, but I don't expect it to have
zero-length file issues? In that case similar to ext3.

> I'm sorry, I won't have the time to do new benchmarks on this.

Me neither.

> The only benchmarks we have have been made by Sven Joachim:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20
> (asyncsync is the switch to sync() instead of fsync() so the opposite of
> the above patch)

Jonathan Nieder also provided some benchmarks in that same bug report
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#25>. And
Modestas Vainius on
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588254>.
Although against slightly later kernel versions, but I don't think
that changes much.

> We really need to upload dpkg this week so we must take a decision what
> goes in.

Well, given #595927/#600075, there does not seem much more we can do
but apply those two patches, so if there's not compelling argument
put forward I'll just be applying them for next release targetting
squeeze.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101117050838.GA20745@gaara.hadrons.org">http://lists.debian.org/20101117050838.GA20745@gaara.hadrons.org
 
Old 11-17-2010, 04:24 AM
Guillem Jover
 
Default Pre-approval request for dpkg sync() changes for squeeze

Hi!

On Mon, 2010-11-15 at 19:31:00 +0100, Philipp Kern wrote:
> On Mon, Nov 15, 2010 at 09:58:47AM +0100, Sven Joachim wrote:
> > All this is with a standard squeeze kernel on an otherwise idle system.
> > It should be noted that with lots of other disk activity such as writing
> > to USB disks, the figures in dpkg 1.15.8.5 can become much worse and
> > dpkg might even stall because of the many sync() calls:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595927.
> >
> > As far as ext4 is concerned, switching back to fsync() seems to be
> > acceptable only if the filesystem is mounted with the nodelalloc
> > option. Maybe the installer should set this up.
>
> and I don't suppose we could make that the default?

That would be the sanest thing to do IMO, otherwise the users might
lose data in general. Barring that probably d-i could set the flag
on newly created file systems. And otherwise as a last resort an entry
on the release notes warning users of the perils of using ext4 with
default options (in addition to the really bad performance with
applications using fsync()) would be nice.

> Is there anything else the dpkg developers can try to be portable
> and still not be sacrificing performance?

It's not much about portability than the side-effects using sync()
entails, as can be seen by the bug report Sven pointed out to. Which
I consider unacceptable for an application to get into. The portability
issues are just a symptom of the wrongness of using sync() as a
subsitute for fsync().

regards,
guillem


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101117052408.GB20745@gaara.hadrons.org">http://lists.debian.org/20101117052408.GB20745@gaara.hadrons.org
 

Thread Tools




All times are GMT. The time now is 01:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org