From owner-freebsd-fs Fri Jan 31 12:41:44 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 EE61937B401 for ; Fri, 31 Jan 2003 12:41:42 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C49F43E4A for ; Fri, 31 Jan 2003 12:41:42 -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 h0VKfe4W039529; Fri, 31 Jan 2003 21:41:40 +0100 (CET) (envelope-from phk@freebsd.org) To: Steve Byan Cc: 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 15:16:37 EST." Date: Fri, 31 Jan 2003 21:41:40 +0100 Message-ID: <39528.1044045700@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 , Steve Byan writes : > >On Friday, January 31, 2003, at 02:08 PM, phk@freebsd.org wrote: > >> 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... > >I keep getting a response that reads like "we'll detect the larger >block size and run with it". I'm concerned that I'm not being clear >that IDEMA is thinking of proposing a backward-compatibility mode with >the presumption that it will work fine (albeit slowly) with existing >binaries, i.e. code that hasn't been modified to be aware of the larger >block size. > >If you think there are no functional problems with this >backwards-compatibility scenario, including during recovery (fsck or >journal roll-forward), I'd be happy to hear a clear "no problem". Ok, to make it 100% clear: 1. We won't see any new problems. The effects of 3.5k around a sector we touched being corrupted is no different from any other 3.5k developing a bad sector read-error. (Hopefully the drive will flag it with a read-error when we come back so it won't look like random data corruption.) 2. Already existing issues will do greater damage. This follows directly from the fact that increasing the sectorsize increases the amount of data lost when a sector is lost. If the market place hates that, the new drives will not be popular there. 3. If the OS can detect the true sectorsize, some choices can be made intelligently and reduce the performance hit and some of recovery issues. -- 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