Cc: Christoph Lameter <clameter@...>, Nick Piggin <nickpiggin@...>, Goswin von Brederlow <brederlo@...>, Andrew Morton <akpm@...>, Joern Engel <joern@...>, <andrea@...>, <torvalds@...>, <linux-fsdevel@...>, <linux-kernel@...>, Christoph Hellwig <hch@...>, William Lee Irwin III <wli@...>, David Chinner <dgc@...>, Jens Axboe <jens.axboe@...>, Badari Pulavarty <pbadari@...>, Maxim Levitsky <maximlevitsky@...>, Fengguang Wu <fengguang.wu@...>, swin wang <wangswin@...>, <totty.lu@...>, <hugh@...>
On Tue, Sep 18, 2007 at 11:00:40AM +0100, Mel Gorman wrote:
No we don't. All workloads benefit from larger block sizes when
you've got a btree tracking 20 million inodes and a create has to
search that tree for a free inode. The tree gets much wider and
hence we take fewer disk seeks to traverse the tree. Same for large
directories, btree's tracking free space, etc - everything goes
faster with a larger filesystem block size because we spent less
time doing metadata I/O.
And the other advantage is that sequential I/O speeds also tend to
increase with larger block sizes. e.g. XFS on an Altix (16k pages)
using 16k block size is about 20-25% faster on writes than 4k block
size. See the graphs at the top of page 12:
http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf
The benefits are really about scalability and with terabyte sized
disks on the market.....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
