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 arou
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 k
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 happen
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_ran
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.
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
Sam
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
On Mon, Nov 29, 2010 at 8:23 PM, Raphael Hertzog wrote:
> (Dropping bug report)
>
> On Mon, 29 Nov 2010, Olaf van der Spek wrote:
>> > Hence the fact that all file system developers, whether they were
>> > btrfs developers or XFS developers or ext4 developers, made the joke
>> > at the file system
(Dropping bug report)
On Mon, 29 Nov 2010, Olaf van der Spek wrote:
> > Hence the fact that all file system developers, whether they were
> > btrfs developers or XFS developers or ext4 developers, made the joke
> > at the file system developers summit two years ago, that what the
> > application p
On Mon, Nov 29, 2010 at 4:18 PM, Ted Ts'o 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 with ext3, or
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
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), permi
On Mon, Nov 29, 2010 at 3:58 PM, Ian Jackson
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
On Mon, Nov 29, 2010 at 2:56 PM, Bastian Blank 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 fsync since a l
On Mon, Nov 29, 2010 at 2:22 PM, 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
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.75
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
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 wrote:
> > I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d)
> > would be best.
>
> Are there any pla
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 t
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:
extract(a)
On Sat, Nov 27, 2010 at 03:54:12PM +0100, Olaf van der Spek wrote:
> On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o 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 in
On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o 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 (because it
* 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 wro
On Sat, Nov 27, 2010 at 11:52:07AM +0100, Guillem Jover wrote:
> Hi!
>
> On Fri, 2010-11-26 at 16:09:10 +0100, Mike Hommey wrote:
> > How about dpkg doesn't care, like it used to, *except* for really
> > important packages (say, essential ones, or priority important, or
> > whatever). Since appare
Hi!
On Fri, 2010-11-26 at 16:09:10 +0100, Mike Hommey wrote:
> How about dpkg doesn't care, like it used to, *except* for really
> important packages (say, essential ones, or priority important, or
> whatever). Since apparently the whole avoid empty files thing is much
> more important for libc th
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/
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
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(
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
>ren
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
* 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-7
On Fri, Nov 26, 2010 at 3:53 PM, Raphael Hertzog wrote:
> It all started with report of corrupted (zero-length) files on ext4/ubifs
> (see http://bugs.debian.org/430958). We did the right thing to fix this
> which is to call fsync() on the fly on each file that dpkg unpacks. That
Is durable requi
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote:
> But right now from the point of view of dpkg maintainers, this bug is a
> "wontfix" at our level.
>
> 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 al
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 Fri,
34 matches
Mail list logo
