In message <E6AEE678-3558-11D7-B26B-00306548867E@maxtor.com>, Steve Byan writes
:
>
>On Friday, January 31, 2003, at 02:08  PM, phk@freebsd.org wrote:
>
>> I get the sense that you want us to say "NOOOO this is HORRIBLE!!!"
>> and you won't stop asking until we do ?
>>
>> You won't have that from this bloke at least.
>>
>> I don't know what the agenda you push are, but I'm not pushing it
>> for you...
>
>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.
>
>If you think there are no functional problems with this 
>backwards-compatibility scenario, including during recovery (fsck or 
>journal roll-forward), I'd be happy to hear a clear "no problem".

Ok, to make it 100% clear:

1. We won't see any new problems.  The effects of 3.5k around a
   sector we touched being corrupted is no different from any other
   3.5k developing a bad sector read-error.   (Hopefully the drive
   will flag it with a read-error when we come back so it won't
   look like random data corruption.)

2. Already existing issues will do greater damage.  This follows
   directly from the fact that increasing the sectorsize increases the
   amount of data lost when a sector is lost.  If the market place
   hates that, the new drives will not be popular there.

3. If the OS can detect the true sectorsize, some choices can
   be made intelligently and reduce the performance hit and
   some of recovery issues.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.