On 6/10/2012 10:21 PM, Linda A. Walsh wrote: > Is this something being thought about?? Probably not much these days, but I'm sure it's been debated much over the years amongst many filesystem and kernel developers across all operating system teams, including Linux, *nix, VMS, MVS, and Windows. ... > All but 2 could benefit from a 16K block size, and 3 of them could benefit > from a 128K block size. Wouldn't that benefit in in freeing up some space > both on disk and in memory? Just a thought. If you could increase the page size and thus the XFS block size to some arbitrarily high number such as 64KB, it would do nothing for on disk layout but increase wasted disk sectors. It would increase transfer performance on some workloads, but it would also cause a myriad of problems. Not least of which is the need to recode, debug, and regression test the entire x86[64] kernel to use properly use 64KB pages, which I assume is no small task. Everything is a tradeoff Linda. At this point, 4KB appears to be the best tradeoff. And again, even if it were increased, it wouldn't do anything to benefit the case the you mention, but would actually hurt it, because you'd end up with more wasted sectors at the end of each file. Array controllers and disks have no awareness of the FS block size. They simply swallow or sling 512B sectors from/to the block layer. It's the block layer that can benefit from being fed larger FS blocks as it can schedule transfers more efficiently. For instance, allowing the elevator the potential to order sector accesses, minimizing head seeks. -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
