From owner-freebsd-fs Fri Jan 31 12:15:28 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 8E64037B401; Fri, 31 Jan 2003 12:15:26 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2A7A43F43; Fri, 31 Jan 2003 12:15:25 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <20030131201519053003msr6e>; Fri, 31 Jan 2003 20:15:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA46356; Fri, 31 Jan 2003 12:15:19 -0800 (PST) Date: Fri, 31 Jan 2003 12:15:17 -0800 (PST) From: Julian Elischer To: David Schultz Cc: Steve Byan , phk@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: DEV_B_SIZE In-Reply-To: <20030131192452.GA15985@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 31 Jan 2003, David Schultz wrote: > 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?) 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message