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
* 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)
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
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will rep
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,
36 matches
Mail list logo
