On Fri, Dec 25, 2009 at 11:14:53AM -0500, [email protected] wrote:
> On Thu, Dec 24, 2009 at 05:52:34PM -0800, Christian Kujau wrote:
> >
> > Well, I do "sync" after each operation, so the data should be on disk, but
> > that doesn't mean it'll clear the filesystem buffers - but this doesn't
> > happen that often in the real world too. Also, all filesystem were tested
> > equally (I hope), yet some filesystem perform better than another - even
> > if all the content copied/tar'ed/removed would perfectly well fit into the
> > machines RAM.
>
> Did you include the "sync" in part of what you timed? Peter was quite
> right --- the fact that the measured bandwidth in your "cp" test is
> five times faster than the disk bandwidth as measured by hdparm, and
> many file systems had exactly the same bandwidth, makes me very
> suspicious that what was being measured was primarily memory bandwidth
> --- and not very useful when trying to measure file system
> performance.
Dudes, sync() doesn't flush the fs cache, you have to unmount for that.
Once upon a time Linux had an ioctl() to flush the fs buffers, I used
it in lmbench.
ioctl(fd, BLKFLSBUF, 0);
No idea if that is still supported, but sync() is a joke for benchmarking.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
