Subject: Re: DEV_B_SIZE
To: Steve Byan <firstname.lastname@example.org>
From: None <email@example.com>
Date: 01/31/2003 18:18:06
In message <F4D99E08-353D-11D7-B26B-00306548867E@maxtor.com>, Steve Byan writes
>On Friday, January 31, 2003, at 11:50 AM, firstname.lastname@example.org wrote:
>> In message <4912E0FE-3539-11D7-B26B-00306548867E@maxtor.com>, Steve
>> Byan writes
>>> 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.
>> If by "hide" you mean that there will be no way to discover the
>> smallest atomic unit of writes, then you are right: it would be bad.
>The notion is that such a disk would be instantly-compatible with
>existing software, modulo performance issues. I suspect this is not the
>case, and am searching for expert opinions in this matter.
I'm fine with that, as long as the disk somewhere in a data field
we can query (if need be with a new request) exposes the smallest
atomically writable unit.
The only thing that exposes us to risk is we don't know the risk
exists, so as long as the fact that a 4k physical sector size is
used is not hidden from us, we can adapt.
>Yes, I understand recompiling the world for 4K is possible. My question
>is whether not doing so poses a data-integrity / fail-recovery risk.
>> It was my impression that already many drives write entire tracks
>> as atomic units, at least we have had plenty of anecdotal evidence
>> to this effect ?
>I'm not aware of any SCSI or ATA disks which do this; certainly no
>Maxtor disk does.
Ok, that is nice to know.
And yes, we've had our trouble with write caches.
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.