On Fri, 31 Jan 2003, Steve Byan wrote:

> I keep getting a response that reads like "we'll detect the larger 
> block size and run with it".  I'm concerned that I'm not being clear 
> that IDEMA is thinking of proposing a backward-compatibility mode with 
> the presumption that it will work fine (albeit slowly) with existing 
> binaries, i.e. code that hasn't been modified to be aware of the larger 
> block size.

Is this the scenario you're worried about?

1) Plug a shiny new 4K type disk into, say, FreeBSD 4.7
2) FreeBSD 4.7 doesn't know about 4K disks, so uses 512 byte mode
3) System configures softupdates and does a newfs
4) ... time passes ...
5) Luser trips over power cord in middle of write and corrupts disk

Question: Does this work any differently given that the disk is 4K working
in 512 compatibility mode vs. a real 512 disk?

I think the answer depends upon the atomicity of the access.  If the drive
working in compatibility mode guarantees that only the new 512 bytes (out
of the total 4096) will be corrupt, things probably work.  If, however,
any of the 4096 bytes can be corrupted, it probably will not.

I assume that the whole reasoning behind moving to 4K size is to extend
the error coding to a larger chunk of bits for less overhead.  If that is
the case, a read-modify-write is likely to clobber any of the 4096 bytes,
and it is not likely to work transparently in compatibility mode under
failure conditions.

-a