面白い。
普通はawkするところをpasteコマンドで改行を+記号に変換し、bcコマンドに食わせる事で足し算だぜーって発想が。
こういう無駄にテクニカルな解法大好き
> > > > 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
someone.
static int dump_write(struct file *file, const void *addr, int nr)
{
return file->f_op->write(file, addr, nr, &file->f_pos) == nr;
}
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
flamewar^H^H^H^H^H^H^Hdiscussion.
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 2.6.29.1 (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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/