Subject: DEV_B_SIZE
To: None <freebsd-fs@FreeBSD.ORG, tech-kern@netbsd.org>
From: Steve Byan <stephen_byan@maxtor.com>
List: tech-kern
Date: 01/31/2003 11:30:18
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.
Performance issues aside, it occurs to me that hiding the underlying
physical block size may break many careful-write and
transaction-logging mechanisms, which may depend on no more than one
block being corrupted during a failure. In IDEMA's proposal, a power
failure during a write of a single 512-byte logical block could result
in the corruption of the full 4K block, i.e. reads of any of the
512-byte logical blocks in that 4K physical block would return an
uncorrectable ECC error.
I'd appreciate hearing examples where hiding the underlying physical
block size would break a file system, database, transaction processing
monitor, or whatever. Please let me know if I may forward your reply
to the committee. Thanks.
Regards,
-Steve
--------
Steve Byan <stephen_byan@maxtor.com>
Design Engineer
Maxtor Corp.
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
(508) 770-3414