Subject: Re: DEV_B_SIZE
To: David Laight <email@example.com>
From: Steve Byan <firstname.lastname@example.org>
Date: 01/31/2003 13:45:03
On Friday, January 31, 2003, at 12:59 PM, David Laight wrote:
> On Fri, Jan 31, 2003 at 11:30:18AM -0500, Steve Byan wrote:
>> There's a notion afoot in IDEMA to enlarge the underlying physical
>> block size of disks to 4096 bytes while keeping a 512-byte logical
>> block size for the interface. Unaligned accesses would involve either
>> read-modify-write or some proprietary mechanism that provides
>> persistence without the latency cost of a read-modify-write.
> There probably ought to be a way of making the larger physical
> size visible to systems that are willing to support larger
> block sizes. That way misaligned transfers would be far less
Yes, of course. But I asked with respect to an issue other than
> One problem to consider is that disks are still partitioned
> on cylinder boundaries. This is largely historic but isn't
> this doen't actually make much sense, since the geometry
> almost certainly varies across the disk and has to be faked
> to fit the ATA CHS limits and (on PCs) the BIOS interface.
> However what it does mean is that a partition could easily
> not start on a 8 (512 byte) sector boundary.
> So misaligned transefers are likely even if the filesystem
> itself is using 4k blocks.
> On a PC the partitioning will typically have the first one
> starting in sector 63, and the others at multiple of 16065
> sectors from the start of the disk).
> This doesn't bode well for getting any aligned transfer
> at all.
We understand that problem. It's just a performance issue. My concern
is that even if we handwave the performance issues, there's an
underlying semantic that would not be satisfied if we were to run
existing software, unmodified, on a disk with an underlying 4K sector
Steve Byan <email@example.com>
333 South Street
Shrewsbury, MA 01545