From owner-freebsd-scsi Thu Sep 21 13:50:44 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id 83DC337B424; Thu, 21 Sep 2000 13:50:40 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id NAA08676; Thu, 21 Sep 2000 13:50:35 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 13:50:34 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1DB@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: "'Marius Bendiksen'" , Mike Smith Cc: freeBSD-scsi@FreeBSD.ORG, "'fs@freeBSD.org'" Subject: RE: disable write caching with softupdates? Date: Thu, 21 Sep 2000 13:39:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > Actually, you can do certain optimizations based on the > knowledge of how > the disk behaves, if you have the ability to use this knowledge in a > realtime system. I unfortunately misphrased so as to state > that FFS did > accurately use this information, which it does not. It would, however, > be possible to design a system which exploits this, thus improving > performance by, amongst other things, removing rotational latency, and > being aware of bad sector remapping, seek timings, zone layout, et al. > This would require realtime operation and fine-grained timing, though. > There are certainly other things one would benefit from first. > > And this still relies on having the drive provide the correct > information, > including such things as temperature, air moisture levels, or > whatever. > This, as you pointed out, is not reported by disk drives. I think this is one of the more interesting things about the NASD and object-based disk proposals. Since they push the file-store layer down to the disk, the block allocation policy can take all of these things into account, without having to specify an intermediate abstraction layer to convey the necessary information, since the form of that information changes frequently as a reflection of the volatility of the underlying technology in the disk drive. Regards, -Steve Steve Byan Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message