[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B36333B.3030600@hp.com>
Date: Sat, 26 Dec 2009 11:00:59 -0500
From: jim owens <jowens@...com>
To: Christian Kujau <lists@...dbynature.de>
CC: Larry McVoy <lm@...mover.com>, tytso@....edu,
jfs-discussion@...ts.sourceforge.net, linux-nilfs@...r.kernel.org,
xfs@....sgi.com, reiserfs-devel@...r.kernel.org,
Peter Grandi <pg_jf2@....for.sabi.co.UK>,
ext-users <ext3-users@...hat.com>, linux-ext4@...r.kernel.org,
linux-btrfs@...r.kernel.org
Subject: Re: [Jfs-discussion] benchmark results
Christian Kujau wrote:
> I was using "sync" to make sure that the data "should" be on the disks
Good, but not good enough for many tests... info sync
CONFORMING TO
POSIX.2
NOTES
On Linux, sync is only guaranteed to schedule the dirty blocks for
writing; it can actually take a short time before all the blocks are
finally written.
This is consistent with all the feels-like-unix OSes I have used.
And to make it even more random, the hardware (drive/controller)
write cache state needs to be accounted for, and what the filesystem
does if anything to try to ensure device-cache-to-media consistency.
That does not mean I'm saying the tests are invalid or not useful,
only that people need to evaluate "what do they really tell me".
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists