Subject: Re: DEV_B_SIZE
To: Steve Byan <>
From: None <>
List: tech-kern
Date: 01/31/2003 18:18:06
In message <>, Steve Byan writes
>On Friday, January 31, 2003, at 11:50  AM, wrote:
>> In message <>, 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.