May 2009



#! /bin/sh
ionice -c3 -p$$

if [ -x /usr/bin/slocate ]


> > > > I dunno. Is this true of all linux filesystems in all cases? Maybe.
> > >
> > > Assuming one of them is not would you rather want to fix that file system
> > > or 10 zillion user programs (including the kernel core dumper) that
> > > get it wrong? @)
> > >
> >
> > I think that removing one bug is better than adding one.
> >
> > Many filesystems will return a short write if they hit a memory
> > allocation failure, for example. pipe_write() sure will. Retrying
> > is appropriate in such a case.
> Sorry but are you really suggesting every program in the world that uses
> write() anywhere should put it into a loop? That seems just like really
> bad API design to me, requiring such contortions in a fundamental
> system call just to work around kernel deficiencies.
> I can just imagine the programmers putting nasty comments
> about the Linux kernel on top of those loops and they would
> be fully deserved.

Hey, don't look at me - blame Brian Kernighan or George Bush or

背景: core dumpをパイプ経由で書き込むときに

static int dump_write(struct file *file, const void *addr, int nr)
return file->f_op->write(file, addr, nr, &file->f_pos) == nr;


Andi Kleen:

Paul Smith:
 うーん、でも多くのファイルシステムがメモリ不足やらなんやらで部分書き込み成功を返すんだよね。ここはcore dumpのところだけ直すのが影響範囲が小さくて・・・
Andi Kleen:

Andrew Morton:
 こっち見んな( ゚Д゚ )

On Wed, May 27, 2009 at 09:24:21AM +0800, Li Zefan wrote:
> Seems Christoph also runs into this problem while doing his XFS tracing.
> (and NULL str ptr that I'm not suffering)

Yeah. What I'm doing is tracing the XFS directory code. For some
reason unknown to mankind people decided not to store the 0 termination
on disk because we have the string length in the dirent anyway. So
beeing able to specify the length is important to me, aswell as dealing
with NULL strings because there are some directory operations that
are internal and don't deal with any entry and thus don't have a name
associated with them.

> > This is why I like the Impact line really be a "rational" line.
> > "TRACE_EVENT api change" is meaningless to me.
> >
> So what should this impact be. :(

Another reason for just dropping the impact Lines. I had hope people
would just stop adding it after the last

口が悪いので、一部で有名なChristoph Hellwig くん。


I'd like to submit TuxOnIce for review, with a view to seeking to get it
merged, perhaps in 2.6.31 or .32 (depending upon what needs work before
it can be merged) and the willingness of those who matter.

To briefly summarise the advantages to merging TuxOnIce:

- Support for multiple swap devices
- Support for non-swap (an ordinary file can be used)
- Uses cryptoapi (LZO support, more than 2x speed of uncompressed data!)
- Asynchronous I/O, readahead, multithreaded. Get the maximum throughput
possible with your hardware.
- Userspace user interface that lets you abort hibernating and abort
resuming, get nice progress display etc.
- 8 years of testing and improvement.
- Full image of memory (LRU pages that don't need to be atomically
copied are saved prior to the atomic copy, then used as the
destination of the atomic copy).
- Support for resuming a different image after writing an image - makes
powering down a UPS after writing an image doable.
- Simple to set up (works without any userspace binaries, uses existing
resume= and noresume commandline parameters).

Signed-off-by: Nigel Cunningham

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at


From: Heinz Diehl
Subject: Re: SSD and IO schedulers

On 08.04.2009, Corrado Zoccolo wrote:

> I found that elevator=deadline performs much better than noop for
> writes, and almost as well for reads

The DL elevator has slightly more throughput than cfq and anticipatory,
but is almost unusuable under load.

Running Theodore Ts'os "fsync-tester" while doing Linus' torture test
"while : ; do time sh -c "dd if=/dev/zero of=bigfile bs=8M count=256 ; sync; rm bigfile"; done"
shows it clearly:

mount: /dev/sda4 on /home type xfs (rw,noatime,logbsize=256k,logbufs=2,nobarrier)
Kernel (vanilla)

with cfq:

htd@liesel:~/!> ./fsync-tester
fsync time: 0.7640
fsync time: 0.6166
fsync time: 1.2830
fsync time: 0.4273
fsync time: 1.1693
fsync time: 1.7466
fsync time: 1.2477
fsync time: 1.9411
fsync time: 1.9636
fsync time: 1.9065
fsync time: 1.1561
fsync time: 1.8267
fsync time: 0.2431
fsync time: 0.2898
fsync time: 0.2394
fsync time: 0.4309
fsync time: 1.5699
fsync time: 0.3742
fsync time: 1.3194
fsync time: 1.9442
fsync time: 1.0899
fsync time: 1.9443
fsync time: 1.0062

with dl:

fsync time: 10.5853
fsync time: 10.3339
fsync time: 5.3374
fsync time: 6.5707
fsync time: 10.6095
fsync time: 4.1154
fsync time: 4.9604
fsync time: 10.5325
fsync time: 10.4543
fsync time: 10.4970
fsync time: 10.5570
fsync time: 5.2717
fsync time: 10.5619
fsync time: 5.3058
fsync time: 3.1019
fsync time: 5.1504
fsync time: 5.7564
fsync time: 10.5998
fsync time: 4.0895

Regards, Heinz.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at