From owner-freebsd-fs Fri Jan 31 11:24:57 2003 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E915237B401; Fri, 31 Jan 2003 11:24:55 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ED2343F75; Fri, 31 Jan 2003 11:24:55 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h0VJOrNt016232; Fri, 31 Jan 2003 11:24:53 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h0VJOrC2016231; Fri, 31 Jan 2003 11:24:53 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Fri, 31 Jan 2003 11:24:52 -0800 From: David Schultz To: Steve Byan Cc: phk@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: DEV_B_SIZE Message-ID: <20030131192452.GA15985@HAL9000.homeunix.com> Mail-Followup-To: Steve Byan , phk@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, tech-kern@netbsd.org References: <2903.1044033486@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake Steve Byan : > >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