On Fri, 31 Jan 2003, David Schultz wrote:

> Thus spake Steve Byan <stephen_byan@maxtor.com>:
> > >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.
> > 
> > But would existing code be functionally broken (perhaps with respect to 
> > failure recovery) if it were to not be modified to adapt to a different 
> > physical block size?
> 
> If the disk corrupts a sector it was writing, that's already a
> problem for us.  If the sector is 4K, that just makes it more of a
> problem.  With FFS and soft updates, we assume that the disk can
> atomically write 512 bytes, and we ensure filesystem consistency
> by establishing a safe partial ordering for metadata updates.  We
> expect that after a crash, either the old contents or the new
> contents of the sector are there.  I think we would need to
> implement journalling to ensure integrity if hard drives were
> likely to corrupt sectors on power failure.  (How often do they do
> this right now, and how often would they with 4K sectors?)


in this case teh journel would have to not only include the block being
written, but data on each side of it that may be in teh same 4k.
that implies a read..


> 
> Inodes are 128 bytes (UFS1) or 256 bytes (UFS2), so a 4K sector
> could contain metadata for a lot of files.  If an indirect block
> is squished, that might be less of a problem because it
> corresponds to only one file.  In one sense, 4K sectors save a
> little bit of space, since directory entries are never split
> across a sector boundary so that they can be updated in a single,
> atomic write.  But large sectors are still worse from a
> reliability point of view if it's possible to lose the entire
> sector.
> 
> The LFS is probably in much better shape...
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message
>