On Fri, 25 Dec 2009 at 10:56, Christian Kujau wrote:
> Thanks for the hint, I could find sys/vm/drop-caches documented in
--^ not, was what I meant to say,
but it's all there, as "drop_caches" in Documentation/sysctl/vm.txt
Christian.
> Documentation/ but it's good to
On Fri, 25 Dec 2009 at 11:33, ty...@mit.edu wrote:
> caches, though; if you are going to measure read as well as writes,
> then you'll probably want to do something like "echo 3 >
> /proc/sys/vm/drop-caches".
Thanks for the hint, I could find sys/vm/drop-caches documented in
Documentation/ but it
On Fri, 25 Dec 2009 at 08:22, Larry McVoy wrote:
> Dudes, sync() doesn't flush the fs cache, you have to unmount for that.
Thanks Larry, that was exactly my point[0] too, I should add that to the
results page to avoid further confusion or misassumptions:
> Well, I do "sync" after each operati
On Fri, 25 Dec 2009 at 11:14, ty...@mit.edu wrote:
> Did you include the "sync" in part of what you timed?
In my "generic" tests[0] I do "sync" after each of the cp/tar/rm
operations.
> Peter was quite
> right --- the fact that the measured bandwidth in your "cp" test is
> five times faster than
On Fri, Dec 25, 2009 at 11:14:53AM -0500, ty...@mit.edu 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
> > hap
On Fri, Dec 25, 2009 at 08:22:38AM -0800, Larry McVoy wrote:
>
> 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 supp
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
>
On Fri, Dec 25, 2009 at 02:46:31AM +0300, Evgeniy Polyakov wrote:
> > [1] http://samba.org/ftp/tridge/dbench/README
>
> Was not able to resist to write a small notice, what no matter what, but
> whatever benchmark is running, it _does_ show system behaviour in one
> or another condition. And when
I'm a file system testing newbie, I have a question/doubt,please let
me know if i'm wrong.
Do you think a tool, which uses output from "hdparm" command,to get
hard drives maximum performance and compares it specific file system
(say for example,"ext4 provides xx throughput against max. device
th
On Friday 25 December 2009, TARUISI Hiroaki wrote:
> I also want to know why this conversion is needed.
> This might be a typo, I think.
>
> Could someone tell us why?
> Can we fix this conversion? Or shouldn't we fix it
> considering back-compatibility?
>
It is even worse: the result code retur
10 matches
Mail list logo