From owner-freebsd-fs Fri Jan 31 13: 6:55 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 A90C637B401; Fri, 31 Jan 2003 13:06:53 -0800 (PST) Received: from mcomail01.maxtor.com (mcomail01.maxtor.com [134.6.76.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id F15B943F79; Fri, 31 Jan 2003 13:06:52 -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 h0VKuNq15356; Fri, 31 Jan 2003 13:56:23 -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 D4XRK8HA; Fri, 31 Jan 2003 14:06:53 -0700 Received: from maxtor.com by mmans02.mma.maxtor.com (8.8.8/1.1.22.3/08May01-0432PM) id QAA0000002539; Fri, 31 Jan 2003 16:06:44 -0500 (EST) Date: Fri, 31 Jan 2003 16:06:43 -0500 Subject: Re: DEV_B_SIZE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Julian Elischer'" , , , To: From: Steve Byan In-Reply-To: <000601c2c962$c04aa2d0$0300a8c0@jkirbydesk> 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 02:55 PM, Jamey Kirby wrote: > Who will do the translation? > > Will there be a device driver that makes the 4K disk look like a 512 > byte disk? No. > If so, the device driver would have to pre-read the 4K, > modify the 512 byte section and re-write the entire 4K. This would kill > performance. Yes, it would. > If this will be handled in the drive, the same sort of logic must be > employed and surly there will be a performance problem; unless the > drive > will be able to write the 512 bytes without a pre-read. Yes, there surely would be a performance problem if the I/O has to wait for a read-modify-write. There may be proprietary techniques for hiding the cost. The assumption is that this is purely a backward-compatibility case, and the performance hit would motivate folks to update their software to recognize the new larger block size. 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