[Top] [All Lists]

Re: block sizes > 4K ?? possible w/large page support?

To: "Linda A. Walsh" <xfs@xxxxxxxxx>
Subject: Re: block sizes > 4K ?? possible w/large page support?
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Mon, 11 Jun 2012 08:13:15 -0500
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <4FD5643F.5070801@xxxxxxxxx>
References: <4FD5643F.5070801@xxxxxxxxx>
Reply-to: stan@xxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
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.


<Prev in Thread] Current Thread [Next in Thread>