On Fri, Sep 4, 2009 at 10:22 AM, Greg Freemyer<greg.freemyer@xxxxxxxxx> wrote: > On Fri, Sep 4, 2009 at 8:59 AM, Rishi Agrawal<rishi.b.agrawal@xxxxxxxxx> wrote: >> I could not figure out the dependency between the file system block size and >> the architecture. >> >> Can somebody guide me in this ? > > Rishi, > > I don't know the answers, but I'm pretty sure your question can be > broken into two. > > 1) Why does the Linux MM system restrict 32-bit kernels to 4K pages? > (Probably has to do with the MMU, but I don't know). It doesn't depend on bitness, but rather, the native page size for the architecture in question. amd64's still using 4k pages, for example. > 2) Why do most linux filesystem use disk blocks <= a memory page? (I > suspect this is tied to the design of the block layer elevators, etc.) If the block was larger than a memory page, the filesystem would have to deal with it being split into two non-contiguous blocks in memory, as using larger allocations causes issues with memory fragmentation. For files this isn't much of a problem, since it needs to deal with this anyway, but for eg directories, it requires additional code to deal with this case. > > fyi: I'm not sure all filesystems have that restriction. So you may > find that 8k blocks are supported with 32-bit kernels in some > filesystems. Indeed, the filesystem can deal with larger block sizes as long as it somehow handles the case of a FS block being split across multiple non-contiguous memory pages. That said, modern filesystems are increasingly extent-based, which eliminates the overhead from small blocks, so they can just use a 4k block size for their internal metadata and not have to worry about it. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
