Re: filesystem benchmarking fun

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 16 May 2007 13:11:56 -0400
Chris Mason <[email protected]> wrote:

> At least on ext3, it may help to sort the blocks under io for
> flushing...it may not.  A bigger log would definitely help, but I would
> say the mkfs defaults should be reasonable for a workload this simple.
> 
> (data=writeback was used for my ext3 numbers).

When ext3 runs out of journal space it needs to sync lots of metadata out
to the fs so that its space in the journal can be reclaimed.  That metadata
is of course splattered all over the place so it's seekstorm time.

The filesystem does take some care to place the metadata blocks "close" to
the data blocks.  But of course if we're writing all the pagecache and then
we later separately go back and write the metadata then that would screw
things up.

I put some code in there which will place indirect blocks under I/O at the
same time as their data blocks, so everything _should_ go out in a nice
slurp (see write_boundary_block()).  The first thing to do here is to check
that write_boundary_block() didn't get broken.

If that's still working then the problem will _probably_ be directory
writeout.  Possibly inodes, but they should be well-laid-out.

Were you using dir_index?  That might be screwing things up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux