Subject: Re: DEV_B_SIZE
To: Steve Byan <stephen_byan@maxtor.com>
From: None <phk@freebsd.org>
List: tech-kern
Date: 01/31/2003 20:08:47
In message <538478DE-354E-11D7-B26B-00306548867E@maxtor.com>, Steve Byan writes
:
>>> Really? fsck can recover from losing 4K bytes surrounding the last
>>> metadata block written?
>>
>> The only metadata that matter are the inodes and (for ffs) the
>> indirect blocks. You do really want the latter to be single disk
>> blocks - many systems actually write them synchonously.
>
>What could be the effect of losing surrounding blocks on the (failed)
>write of an indirect block? Can we guarantee that fsck can reconstruct
>the filesystem, modulo some recently-created or deleted files, or is
>there a possibility of losing the entire filesystem?
For inodes the situation is no different, only the exposure is greater:
instead of loosing three neighbour inodes we loose 31 neighbour inodes.
(Or for ufs2: 1 vs 15 inodes).
As long as I can ask the drive what the size of an atomic transfer
is it doesn't matter much to us if it is 512, 1k, 2k or 4k. Going
above 4k would probably be a bit premature and therefore inconvenient.
If drives that come out with 4k sectors end up trashing too much
data for people, they will get a bad reputation rather fast and
I'm sure market mechanisms will take care of the issue. If they
exhibit no worse losses than we already see due to write caching
and bugs in same, then the market won't react and you guys can
squeeze another N% more diskspace out of the same platter.
(I may be an anomaly in this, but I have actually worked on systems
which used 1k sectorsize on their 8" floppies when they made backup
copies to increase the capacity a small bit.)
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...
Poul-Henning
--
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.