Subject: Re: DEV_B_SIZE
To: Steve Byan <firstname.lastname@example.org>
From: None <email@example.com>
Date: 01/31/2003 21:41:40
In message <E6AEE678-3558-11D7-B26B-00306548867E@maxtor.com>, Steve Byan writes
>On Friday, January 31, 2003, at 02:08 PM, firstname.lastname@example.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
>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.