On Fri, 06 Oct 2006 14:31:59 +0400 Alex Tomas <alex@xxxxxxxxxxxxx> wrote: > >>>>> Andrew Morton (AM) writes: > > AM> On Fri, 6 Oct 2006 00:41:03 -0600 > AM> Andreas Dilger <adilger@xxxxxxxxxxxxx> wrote: > > >> The big performance win will come with mballoc and delalloc. CFS has > >> been using mballoc for a few years already with Lustre, and IBM + Bull > >> did a lot of benchmarking on it. The reason it isn't in the first set of > >> patches is partly a manageability issue, and partly because it doesn't > >> directly affect the on-disk format (outside of much better allocation) > >> so it isn't critical to get into the first round of changes. I believe > >> Alex is working on a new set of patches right now. > > AM> Are you sure that these things will improve allocation much? Reservations > AM> made a big improvement there. > > it depends on underlaying storage and workload. mballoc uses buddy > internally. it's much simpler and cheaper to find free 2^N blocks > compared to bitmap. So mballoc's application is to save CPU cycles? > this is especially important for arrays like > DDN and raid5/6 because they require stripe-aligned/-sized requests > for good throughput. Does this not imply that there needs to be new linkage between the filesystem and the lower layers? So that raid/etc can inform the filesystem driver about its alignment and striping requirements? > also, last mballoc takes logical block into > account and can preallocate few chunks at different logical offsets > for a file. imagine torrent downloading different pieces from few peers. hm. You don't need anything as exotic as bittorrent to show up problems in that area: box:/usr/src/25> sudo bmap vmlinux | wc -l 1152 - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
