From owner-freebsd-fs Fri Jan 31 9: 4: 2 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 C6E5637B401; Fri, 31 Jan 2003 09:04:00 -0800 (PST) Received: from mcomail01.maxtor.com (mcomail01.maxtor.com [134.6.76.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47CD243E4A; Fri, 31 Jan 2003 09:03:59 -0800 (PST) (envelope-from stephen_byan@maxtor.com) Received: from mcoexc03.mlm.maxtor.com (localhost.localdomain [127.0.0.1]) by mcomail01.maxtor.com (8.11.6/8.11.6) with ESMTP id h0VGrUI31927; Fri, 31 Jan 2003 09:53:30 -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 D4XRKTKZ; Fri, 31 Jan 2003 10:03:58 -0700 Received: from maxtor.com by mmans02.mma.maxtor.com (8.8.8/1.1.22.3/08May01-0432PM) id MAA0000001510; Fri, 31 Jan 2003 12:03:46 -0500 (EST) Date: Fri, 31 Jan 2003 12:03:44 -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: <2639.1044031853@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 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. > Provided we can get the size of the smallest atomic unit of writes > in a standardized, documented, mandatory way, we will have no problem > coping with it: Using a 4k size is no problem for our current > filesystem technologies and device sizes. Yes, I understand recompiling the world for 4K is possible. My question is whether not doing so poses a data-integrity / fail-recovery risk. > It was my impression that already many drives write entire tracks > as atomic units, at least we have had plenty of anecdotal evidence > to this effect ? I'm not aware of any SCSI or ATA disks which do this; certainly no Maxtor disk does. Count-key-data mainframe disks can be formatted to do so, but such disks probably don't run Unix. Caching in ATA disks might lead one to believe that the disk could corrupt an entire track, in the sense that a panic ( aka bluescreen) or a power-failure would cause all pending writes in its buffer to be lost, but even in ATA-land I don't believe a power failure would result in more than one disk block returning an uncorrectable read error. 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