From owner-freebsd-fs Fri Jan 31 8:30:51 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 96FF237B401 for ; Fri, 31 Jan 2003 08:30:50 -0800 (PST) Received: from mcomail02.maxtor.com (mcomail02.maxtor.com [134.6.76.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF07943F43 for ; Fri, 31 Jan 2003 08:30: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 h0VGOOX00470; Fri, 31 Jan 2003 09:24:24 -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 D4XRKRXR; Fri, 31 Jan 2003 09:30:47 -0700 Received: from maxtor.com by mmans02.mma.maxtor.com (8.8.8/1.1.22.3/08May01-0432PM) id LAA0000001462; Fri, 31 Jan 2003 11:30:20 -0500 (EST) Date: Fri, 31 Jan 2003 11:30:18 -0500 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: DEV_B_SIZE From: Steve Byan To: freebsd-fs@FreeBSD.ORG, tech-kern@netbsd.org Content-Transfer-Encoding: 7bit Message-Id: <4912E0FE-3539-11D7-B26B-00306548867E@maxtor.com> 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 There's a notion afoot in IDEMA to enlarge the underlying physical block size of disks to 4096 bytes while keeping a 512-byte logical block size for the interface. Unaligned accesses would involve either a read-modify-write or some proprietary mechanism that provides persistence without the latency cost of a read-modify-write. Performance issues aside, it occurs to me that hiding the underlying physical block size may break many careful-write and transaction-logging mechanisms, which may depend on no more than one block being corrupted during a failure. In IDEMA's proposal, a power failure during a write of a single 512-byte logical block could result in the corruption of the full 4K block, i.e. reads of any of the 512-byte logical blocks in that 4K physical block would return an uncorrectable ECC error. 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. 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