Hi,
finally, this bug is getting fixed.
I have tried to build new dpkg 1.15.8.7 from sid GIT branch [1].
Looks like autpoint is missing in the Build-Depends (see below P.S.).
# apt-get install autopoint
...helps to build the Debian package.
Regards,
- Sedat -
[1]
On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
What's going on here? sync_file_range() is a Linux specific system
call that has been around for a while. It allows program to control
when writeback happens in a very low-level fashion. The first set of
sync_file_range()
Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit :
On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
What's going on here? sync_file_range() is a Linux specific system
call that has been around for a while. It allows program to control
when writeback happens in a
On Tue, Nov 30, 2010 at 10:35:11AM +0100, Samuel Thibault wrote:
Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit :
On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel
On Tue, Nov 30, 2010 at 10:35:11AM +0100, Samuel Thibault wrote:
Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit :
On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
What's going on here? sync_file_range() is a Linux specific system
call that has been around for a
On Mon, 29 Nov 2010, Jonathan Nieder wrote:
Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?
Probably a silly
Olaf van der Spek writes (Re: Bug#605009: serious performance regression with
ext4):
On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o ty...@mit.edu wrote:
I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d)
would be best.
Are there any plans to provide an API for atomic (non
On 29.11.2010 07:18, Guillem Jover wrote:
Could someone with ext4/btrfs/xfs/etc test w/ and w/o the attached patch
against dpkg?
I'm using ext4 (as already mentioned), my small benchmark is (re)installing
vim-runtime using dpkg -i
1.15.8.5:
real0m9.259s
user0m4.212s
sys 0m0.752s
On Mon, Nov 29, 2010 at 01:22:25PM +, Ian Jackson wrote:
Olaf van der Spek writes (Re: Bug#605009: serious performance regression
with ext4):
Are there any plans to provide an API for atomic (non-durable) file
updates, not involving fsync?
Yes. Such an API has already been defined
On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote:
It means we don't need to keep it in RAM since we're not going to
read/modifiy it again in the near future. Thus the writeback can be
started right now since delaying it will not save us anything.
At least that's the way I
On Mon, Nov 29, 2010 at 2:22 PM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
Olaf van der Spek writes (Re: Bug#605009: serious performance regression
with ext4):
Are there any plans to provide an API for atomic (non-durable) file
updates, not involving fsync?
Yes. Such an API has
On Mon, Nov 29, 2010 at 2:56 PM, Bastian Blank wa...@debian.org wrote:
Again: Please quote the standard instead of crying. Your view of things
disallows many of the recent improvements in filesystems, so you have to
show evidence. All the databases and other reliable data handing tools
uses
Olaf van der Spek writes (Re: Bug#605009: serious performance regression with
ext4):
Probably not an issue for dpkg, but in general:
Don't you reset meta-data that way?
Yes. If you want to keep the metadata you must copy it.
Require a second file (name), permission to write to it and assume
On Mon, Nov 29, 2010 at 3:58 PM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
Olaf van der Spek writes (Re: Bug#605009: serious performance regression
with ext4):
Probably not an issue for dpkg, but in general:
Don't you reset meta-data that way?
Yes. If you want to keep the metadata
On Mon, Nov 29, 2010 at 02:58:16PM +, Ian Jackson wrote:
This is the standard way that ordinary files for which reliability was
important have been updated on Unix for decades. fsync is for files
which need synchronisation with things external to the computer (or at
least, external to
Ted Ts'o wrote:
On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote:
It means we don't need to keep it in RAM since we're not going to
read/modifiy it again in the near future. Thus the writeback can be
started right now since delaying it will not save us anything.
At least
On Mon, Nov 29, 2010 at 4:18 PM, Ted Ts'o ty...@mit.edu wrote:
Lots of users have complained about the desktop performance problem,
but the reality is we can't really solve that without also taking away
the magic that made (c) happen. Whether you solve it by using
data=writeback and stick
On Mon, Nov 29, 2010 at 09:21:44AM -0600, Jonathan Nieder wrote:
That explanation helps a lot. Thanks, both. (Guillem, I like your
patch very much then. Most files being unpacked in a dpkg run aren't
going to be read back again soon. Perhaps some other kernels will
also interpret it as a
On Mon, Nov 29, 2010 at 10:32:44AM -0500, Ted Ts'o wrote:
Most files won't, but consider a postinstall script which needs to
scan/index a documentation file, or simply run one or more binaries
that was just installed. I can definitely imagine situations where
using POSIX_FADV_DONTNEED could
Ted Ts'o wrote:
Most files won't, but consider a postinstall script which needs to
scan/index a documentation file, or simply run one or more binaries
that was just installed. I can definitely imagine situations where
using POSIX_FADV_DONTNEED could actually hurt performance.
Hmm. Maybe
On 29.11.2010 14:41, Michael Biebl wrote:
I'm using ext4 (as already mentioned), my small benchmark is (re)installing
vim-runtime using dpkg -i
1.15.8.5:
real0m9.259s
user0m4.212s
sys 0m0.752s
1.15.8.6:
real0m41.766s
user0m4.248s
sys 0m1.028s
1.15.8.6
On 29.11.2010 14:41, Michael Biebl wrote:
On 29.11.2010 07:18, Guillem Jover wrote:
Could someone with ext4/btrfs/xfs/etc test w/ and w/o the attached patch
against dpkg?
I'm using ext4 (as already mentioned), my small benchmark is (re)installing
vim-runtime using dpkg -i
Same test on
Hi,
On Tue, 30 Nov 2010, Michael Biebl wrote:
Something interesting I noticed:
I created the ext4 file system on a spare partition and installed a chroot.
After running the test, I exited the chroot, immediately unmounted the
partition
and measured how long it took:
1.15.8.5: 0.4s
I did some experimenting, and I figured out what was going on. You're
right, (c) doesn't quite work, because delayed allocation meant that
the writeout didn't take place until the fsync() for each file
happened. I didn't see this at first; my apologies.
However, this *does* work:
Hi Ted!
On Sun, 2010-11-28 at 23:11:52 -0500, Ted Ts'o wrote:
I did some experimenting, and I figured out what was going on. You're
right, (c) doesn't quite work, because delayed allocation meant that
the writeout didn't take place until the fsync() for each file
happened. I didn't see this
(pruned cc list)
Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?
Probably a silly question, but what does The specified
Hi Guillem,
Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?
Could someone with ext4/btrfs/xfs/etc test w/ and w/o the
Hi Ted,
Ted Ts'o wrote:
1) Suppose package contains files a, b, and c. Which are you
doing?
a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a);
extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b);
extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new,
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 16:33:06 +0100):
On Fri, 26 Nov 2010, Mathias Behrle wrote:
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri,
26 Nov 2010 15:53:27 +0100):
That was ok everywhere except on ext4
On Sat, 27 Nov 2010, Jonathan Nieder wrote:
c) extract(a.dpkg-new);
extract(b.dpkg-new);
extract(c.dpkg-new);
fsync(a.dpkg-new);
fsync(b.dpkg-new);
fsync(c.dpkg-new);
rename(a.dpkg-new, a);
rename(b.dpkg-new, b);
rename(c.dpkg-new, c);
(c)
Hi!
On Fri, 2010-11-26 at 16:52:54 -0500, Ted Ts'o wrote:
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote:
Just to sum up what dpkg --unpack does in 1.15.8.6:
1/ set the package status as half-installed/reinst-required
2/ extract all the new files as *.dpkg-new
3/ for all
* Betr.: Fw: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 22:15:06 +0100):
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 16:33:06 +0100):
On Fri, 26 Nov 2010, Mathias Behrle wrote:
* Betr.: Re: Bug#605009: serious
On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o ty...@mit.edu wrote:
I am guessing you are doing (a) today --- am I right? (c) or (d)
would be best.
Are there any plans to provide an API for atomic (non-durable) file
updates, not involving fsync?
Would be simpler (for apps), faster and more general
Package: dpkg
Version: 1.15.8.6
Severity: important
Hi!
I'm using ext4 with the default mount option and the fs was created with
the default settings from /etc/mke2fs.conf.
Since the latest upgrade, performance suffered badly.
E.g. installing vim-runtime took ~8 secs with 1.15.8.5, now it takes
Hi,
adding debian-devel, debian-boot, debian-kernel and Theodore Y. Ts'o in CC
because I'm fed up with this problem. Sorry for the massive crosspost, you
might want to follow up only on -devel and on the bug report.
Some clones/reassign should probably result from this discussion anyway.
On
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 15:53:27 +0100):
That was ok everywhere except on ext4.
JFTR: I am experiencing those problems as well on XFS.
Cheers,
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Low performance with Btrfs as well, :(
(Even Btrfs is not supported in squeeze, I think this could help on
digging whether it is a more generic problem than EXT4 only.)
--
Regards,
Aron Xu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Hi,
On Fri, 26 Nov 2010, Mathias Behrle wrote:
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 15:53:27 +0100):
That was ok everywhere except on ext4.
JFTR: I am experiencing those problems as well on XFS.
Can you give us figures to quantify
I'm reinstalling vim-runtime using the following command to do this benchmark:
$ time sudo dpkg -i vim-runtime_7.2.330-1ubuntu3_all.deb
Results:
1.15.8.5: 3.02s user 1.96s system 16% cpu 30.364 total
1.15.8.6: 3.48s user 2.86s system 9% cpu 1:04.43 total
My system infomation:
$ lsb_release -a
No
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 16:33:06 +0100):
On Fri, 26 Nov 2010, Mathias Behrle wrote:
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri,
26 Nov 2010 15:53:27 +0100):
That was ok everywhere except on ext4
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote:
Just to sum up what dpkg --unpack does in 1.15.8.6:
1/ set the package status as half-installed/reinst-required
2/ extract all the new files as *.dpkg-new
3/ for all the unpacked files: fsync(foo.dpkg-new) followed by
41 matches
Mail list logo
