Subject: Re: DEV_B_SIZE
To: Steve Byan <email@example.com>
From: Lord Isildur <firstname.lastname@example.org>
Date: 01/31/2003 13:51:52
to just get the performance of aligned accesses, we dont need to modify
block sizes and such stuff. an an example, read the paper linked to from
(brought to you by the same folks who did soft updates and raidframe)
On Fri, 31 Jan 2003, Steve Byan wrote:
> 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
> >> a
> >> 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
> > likely.
> 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>
> Design Engineer
> Maxtor Corp.
> MS 1-3/E23
> 333 South Street
> Shrewsbury, MA 01545
> (508) 770-3414