Date: Thu, 21 Sep 2000 12:32:22 -0700 From: Mike Smith <msmith@freebsd.org> To: Marius Bendiksen <mbendiks@eunet.no> Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? Message-ID: <200009211932.MAA01341@mass.osd.bsdi.com> In-Reply-To: Your message of "Thu, 21 Sep 2000 20:33:14 %2B0200." <Pine.BSF.4.05.10009212022040.41458-100000@login-1.eunet.no>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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? No. But I said "I think" as well. > > > 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. Not really. You link "real" geometries with "all the stuff FFS does to exploit it". FFS' attempts to "exploit" drive geometry are intentionally disabled because they don't work. As was pointed out by another poster, unless you have a good drive access model in the time domain, these optimisations are typically pessimisations anyway. Given that the interaction between code and disk has become significantly further decoupled over the years, and given that many of the parameters of this time domain model are extremely context-sensitive (system performance, controller performance, bus load, disk behaviour), the entire field represents an enormous amount of work for dubious return. In no way does it make sense to allude to the mid-80's style optimisations in FFS and refer to "real" geometries as if there was some trivial way to make everything wonderful again by just getting the "real" geometries right. > 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 ultimately we're in more or less violent agreement. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] 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?200009211932.MAA01341>