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