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?)

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...