From owner-freebsd-fs Fri Jan 31 14:46:33 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 7EF4937B401; Fri, 31 Jan 2003 14:46:32 -0800 (PST) Received: from mail.allcaps.org (allcaps.org [216.240.173.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E18943F85; Fri, 31 Jan 2003 14:46:32 -0800 (PST) (envelope-from bsder@allcaps.org) Received: from mail.allcaps.org (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id EB39392FA9; Fri, 31 Jan 2003 17:46:27 -0500 (EST) Received: from localhost (bsder@localhost) by mail.allcaps.org (8.12.5/8.12.5/Submit) with ESMTP id h0VMkR90000481; Fri, 31 Jan 2003 14:46:27 -0800 X-Authentication-Warning: mail.allcaps.org: bsder owned process doing -bs Date: Fri, 31 Jan 2003 14:46:27 -0800 (PST) From: "Andrew P. Lentvorski, Jr." To: Steve Byan Cc: phk@freebsd.org, , Subject: Re: DEV_B_SIZE In-Reply-To: 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, Steve Byan wrote: > 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. Is this the scenario you're worried about? 1) Plug a shiny new 4K type disk into, say, FreeBSD 4.7 2) FreeBSD 4.7 doesn't know about 4K disks, so uses 512 byte mode 3) System configures softupdates and does a newfs 4) ... time passes ... 5) Luser trips over power cord in middle of write and corrupts disk Question: Does this work any differently given that the disk is 4K working in 512 compatibility mode vs. a real 512 disk? I think the answer depends upon the atomicity of the access. If the drive working in compatibility mode guarantees that only the new 512 bytes (out of the total 4096) will be corrupt, things probably work. If, however, any of the 4096 bytes can be corrupted, it probably will not. I assume that the whole reasoning behind moving to 4K size is to extend the error coding to a larger chunk of bits for less overhead. If that is the case, a read-modify-write is likely to clobber any of the 4096 bytes, and it is not likely to work transparently in compatibility mode under failure conditions. -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message