From owner-freebsd-fs Fri Jan 31 10:41:52 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 3DC5A37B401; Fri, 31 Jan 2003 10:41:50 -0800 (PST) Received: from mcomail02.maxtor.com (mcomail02.maxtor.com [134.6.76.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 683B243F93; Fri, 31 Jan 2003 10:41:49 -0800 (PST) (envelope-from stephen_byan@maxtor.com) Received: from mcoexc03.mlm.maxtor.com (localhost.localdomain [127.0.0.1]) by mcomail02.maxtor.com (8.11.6/8.11.6) with ESMTP id h0VIZQU16809; Fri, 31 Jan 2003 11:35:26 -0700 Received: from mmans02.mma.maxtor.com ([134.6.232.101]) by mcoexc03.mlm.maxtor.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D4XRKX44; Fri, 31 Jan 2003 11:41:48 -0700 Received: from maxtor.com by mmans02.mma.maxtor.com (8.8.8/1.1.22.3/08May01-0432PM) id NAA0000002101; Fri, 31 Jan 2003 13:41:36 -0500 (EST) Date: Fri, 31 Jan 2003 13:41:35 -0500 Subject: Re: DEV_B_SIZE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: freebsd-fs@freebsd.org, tech-kern@netbsd.org To: phk@freebsd.org From: Steve Byan In-Reply-To: <2903.1044033486@critter.freebsd.dk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Friday, January 31, 2003, at 12:18 PM, phk@freebsd.org wrote: > In message , Steve > Byan writes > : >> >> On Friday, January 31, 2003, at 11:50 AM, phk@freebsd.org wrote: >> >>> In message <4912E0FE-3539-11D7-B26B-00306548867E@maxtor.com>, Steve >>> Byan writes >>> : >>> >>>> I'd appreciate hearing examples where hiding the underlying physical >>>> block size would break a file system, database, transaction >>>> processing >>>> monitor, or whatever. Please let me know if I may forward your >>>> reply >>>> to the committee. Thanks. >>> >>> If by "hide" you mean that there will be no way to discover the >>> smallest atomic unit of writes, then you are right: it would be bad. >> >> The notion is that such a disk would be instantly-compatible with >> existing software, modulo performance issues. I suspect this is not >> the >> case, and am searching for expert opinions in this matter. > > I'm fine with that, as long as the disk somewhere in a data field > we can query (if need be with a new request) exposes the smallest > atomically writable unit. > > 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? > >> Yes, I understand recompiling the world for 4K is possible. My >> question >> is whether not doing so poses a data-integrity / fail-recovery risk. > > Nope. Really? fsck can recover from losing 4K bytes surrounding the last metadata block written? Regards, -Steve -------- Steve Byan Design Engineer Maxtor Corp. MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508) 770-3414 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message