Thomas King wrote:
> -Concerning the block-size limit, will this eventually be a thing of the past?
> Mr. Newman's contention is massive filesystems should have much larger block
> sizes, but he also contends that OSD is the eventual answer instead of using
> block allocation.
Just to reiterate what I already put on the ext4 list... :)
ftp://ftp.kernel.org/pub/linux/kernel/people/christoph/largeblocksize/4/patches/
http://kerneltrap.org/Linux/Large_Blocksize_Performance
Not sure where those patches are headed.
It's also not clear to me that this is really a critical feature for
large filesystems; space allocation is not done block by block per se in
xfs, as Mr. Newman seems (?) to imply (?) The block granularity is
there throughout the fs but I'm not sure how much it matters in
practice. Dave...?
OSDs may have their place, we'll see. It's pretty new stuff (unless you
count Lustre, I guess, but I thought he didn't want to talk lustre...)
I don't think this relates to a linux shortcoming in any way (or to
xfs...), it's awfully new stuff that just about nobody really has in
production.
> -Is there anything else y'all would like folks to understand about XFS and
> massive implementations?
I already pointed him at the xfs_repair paper, since he seems concerned
about fsck (and pointed out that yes, xfs_repair really *DOES* check all
filesystem data and does not simply replay the log...)
http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf
Maybe some of the folks on the list with said massive implementations
can speak up too. :)
-Eric
|