From owner-freebsd-fs Fri Jan 31 11: 6:17 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 B1FEA37B401; Fri, 31 Jan 2003 11:06:15 -0800 (PST) Received: from mcomail02.maxtor.com (mcomail02.maxtor.com [134.6.76.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1190343F3F; Fri, 31 Jan 2003 11:06:15 -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 h0VIxqN25634; Fri, 31 Jan 2003 11:59:52 -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 D4XRKYTB; Fri, 31 Jan 2003 12:06:14 -0700 Received: from maxtor.com by mmans02.mma.maxtor.com (8.8.8/1.1.22.3/08May01-0432PM) id OAA0000002262; Fri, 31 Jan 2003 14:06:13 -0500 (EST) Date: Fri, 31 Jan 2003 14:06:11 -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: <19187.1044039084@critter.freebsd.dk> Message-Id: <1010FEB6-354F-11D7-B26B-00306548867E@maxtor.com> 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 01:51 PM, phk@freebsd.org wrote: > In message , Steve > Byan writes > : > >>> 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? > > Not broken any worse than because of write-caching. Agreed, but IDEMA is proposing to do this to SCSI drives, too. > >>> Nope. >> >> Really? fsck can recover from losing 4K bytes surrounding the last >> metadata block written? > > If the fragment size is 4k when the filsystem is created, and this > would happen automatically, then there is no window for lossage. But if someone were to plug a new 4K-block disk into a system compiled to use 512 byte block disks, and the SCSI interface were faked to make it appear that the disk could read and write 512-byte blocks, then what happens? IDEMA's notion is that faking 512-byte logical size is good enough to get new disks to work in systems running legacy code. My fear is that it is not so simple. > > The thing we really need is working tagged-queing... Since I believe tagged-queuing works in SCSI, I assume you are asking for it in ATA? Or is there some feature missing from SCSI tagged-queuing that you'd like to see? 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