Messages in this thread | | | Date | Wed, 16 May 2007 11:25:15 -0700 | From | Andrew Morton <> | Subject | Re: filesystem benchmarking fun |
| |
On Wed, 16 May 2007 13:11:56 -0400 Chris Mason <chris.mason@oracle.com> 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 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/
| |