Date: Fri, 31 Jan 2003 11:24:52 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Steve Byan <stephen_byan@maxtor.com> Cc: phk@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: DEV_B_SIZE Message-ID: <20030131192452.GA15985@HAL9000.homeunix.com> In-Reply-To: <A02737C6-354B-11D7-B26B-00306548867E@maxtor.com> References: <2903.1044033486@critter.freebsd.dk> <A02737C6-354B-11D7-B26B-00306548867E@maxtor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030131192452.GA15985>