From owner-freebsd-fs Fri Jan 31 11: 9: 4 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 46A0B37B401 for ; Fri, 31 Jan 2003 11:09:03 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD5C943F85 for ; Fri, 31 Jan 2003 11:09:01 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0VJ8l4W022439; Fri, 31 Jan 2003 20:08:48 +0100 (CET) (envelope-from phk@freebsd.org) To: Steve Byan Cc: David Laight , freebsd-fs@freebsd.org, tech-kern@netbsd.org Subject: Re: DEV_B_SIZE From: phk@freebsd.org In-Reply-To: Your message of "Fri, 31 Jan 2003 14:00:55 EST." <538478DE-354E-11D7-B26B-00306548867E@maxtor.com> Date: Fri, 31 Jan 2003 20:08:47 +0100 Message-ID: <22438.1044040127@critter.freebsd.dk> 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 In message <538478DE-354E-11D7-B26B-00306548867E@maxtor.com>, Steve Byan writes : >>> Really? fsck can recover from losing 4K bytes surrounding the last >>> metadata block written? >> >> The only metadata that matter are the inodes and (for ffs) the >> indirect blocks. You do really want the latter to be single disk >> blocks - many systems actually write them synchonously. > >What could be the effect of losing surrounding blocks on the (failed) >write of an indirect block? Can we guarantee that fsck can reconstruct >the filesystem, modulo some recently-created or deleted files, or is >there a possibility of losing the entire filesystem? For inodes the situation is no different, only the exposure is greater: instead of loosing three neighbour inodes we loose 31 neighbour inodes. (Or for ufs2: 1 vs 15 inodes). As long as I can ask the drive what the size of an atomic transfer is it doesn't matter much to us if it is 512, 1k, 2k or 4k. Going above 4k would probably be a bit premature and therefore inconvenient. If drives that come out with 4k sectors end up trashing too much data for people, they will get a bad reputation rather fast and I'm sure market mechanisms will take care of the issue. If they exhibit no worse losses than we already see due to write caching and bugs in same, then the market won't react and you guys can squeeze another N% more diskspace out of the same platter. (I may be an anomaly in this, but I have actually worked on systems which used 1k sectorsize on their 8" floppies when they made backup copies to increase the capacity a small bit.) I get the sense that you want us to say "NOOOO this is HORRIBLE!!!" and you won't stop asking until we do ? You won't have that from this bloke at least. I don't know what the agenda you push are, but I'm not pushing it for you... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message