Date: Thu, 21 Sep 2000 20:33:14 +0200 (CEST) From: Marius Bendiksen <mbendiks@eunet.no> To: Mike Smith <msmith@FreeBSD.ORG> Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? Message-ID: <Pine.BSF.4.05.10009212022040.41458-100000@login-1.eunet.no> In-Reply-To: <200009211710.KAA00784@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > That's the price of having a recoverable file system. See Seltzer, Ganger, > > Not necessarily. > Er, you're being both contrary and plain wrong. It's a fundamental > assumption of the softupdates implementation that it is possible to issue > an ordered write and have it complete in an ordered fashion. Mike, I was not making the statement that it was not necessary for softupdates and FFS. I was stating that it is possible to design a filesystem in such a fashion that ordering of writes will be less, if any, of a concern. HAS-FS, for example, is not sensitive to the ordering of writes, as I recall. > > I think you will see that on some drives, this may have a greater > > performance impact than not caching at all. > I think that you should perform some objective research on this first. > Note that the CAM subsystem already correctly honours BIO_ORDERED by > using ordered tags. Allow me to point out that I said "I think". I apologize if expressing an assumption, _with_ the necessary qualifier "think", is improper. Do you have any suggestion as to what I may use to indicate something that I think, rather than know, other than saying "think", without making the statement very long? If necessary, I am certainly willing to start using the following wording: I am not certain about this, however, I would assume that on some drives, you may see a greater impact from this than you would by disabling caching. As noted, this is only speculation, though. > > Actually, performance-wise, you'd probably want to know the real geometry, > > given all the stuff FFS does to exploit it. > Since a) drives don't have 'real' geometries, and haven't for the last > half of the last decade at least, Drives have real geometries. The firmware obviously doesn't store things in the ether or anything. However, I have already noted, as have most of the other people in the thread, that these real geometries are often, or always, highly complex, and are therefore masked by the firmware. I hope this elaboration clarifies things. > and b) we intentionally disable most of these optimisations because > they're founded on assumptions that stopped being relevant a good five > years before *that*... no, you don't care about the drive's geometry at > all. 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. Again, hope these things clarify. Yours, Marius Bendiksen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10009212022040.41458-100000>