Date: Thu, 7 Feb 2002 21:36:11 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: Terry Lambert <tlambert2@mindspring.com> Cc: Josef Karthauser <joe@tao.org.uk>, "Eugene M. Kim" <gene@nttmcl.com>, Oliver Fromme <olli@secnetix.de>, FreeBSD Hardware Mailing List <hardware@FreeBSD.ORG>, FreeBSD Hackers Mailing List <hackers@FreeBSD.ORG> Subject: Re: USB "Memorybird" quirks Message-ID: <20020207205736.W1763-100000@gerard> In-Reply-To: <3C64196C.CC0318FD@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Feb 2002, Terry Lambert wrote: > G=E9rard Roudier wrote: > > A couple of READ/WRITE 6 byte commands are still mandatory for SCSI blo= ck > > devices in order to accomodate softwares as boot software for example t= hat > > may not be upgradable on systems still in use. > > Not a real problem, since if the device doesn't support > the 5 byte commands, it's not booting with the legacy > system software anyway, since you can't boot legacy stuff > on it. > > > > Softwares that are > > maintained should no longer use 6 byte commands, but use the 10 byte > > commands replacement (for years...). > > This I don't understand. FreeBSD appears to have a > preference for the 6 byte commands in the drivers, > which are only used after boot. > > Further, it makes sense that you'd prefer 6 byte if > you could, since it makes your commands 60% smaller, > which should make them faster. The gain is probably no more that 1 microsecond and only applies to the first GB of hard disks (Logical Block Address is 21 bits). There are tons of other places where optimizations are more relevant than sticking with such a questionnable 6 byte commands preference in my humble opinion. Note that not only FreeBSD seems to want not to change this. > > So, unless we want to accomodate applications that still may send 6 byt= e > > commands through passthrough driver, no translator should be needed. Ju= st > > make class drivers use 10 byte commands instead. > > There has to be a reason that FreeBSD has a preference > for 6 bytes in the CAM code... ?!? The main reason could well be that I'm not the maintainer of this code. :-) > > OTOH, using 6 byte READ/WRITE commands is very restrictive if we ever w= ant > > to implemement kind of trustable disk write caching support since they = do > > not allow to selectively force media access (this is achieved by the FU= A > > bit in >=3D 10 byte READ/WRITE command). > > > > As a result, no device should be quirked nowadays as failing READ/WRITE= 6 > > byte commands. Just maintained softwares should get rid of those comman= ds > > asap. > > It sounds like devices that only support 6 byte commands > are the ones that need quirked? Speaking about direct access devices, may-be none has to be so or just a few number of them: - SCSI-1 devices only knew about READ(6)/WRITE(6) commands. - SCSI-2 made READ(10) mandatory, WRITE(10) being optional but just because read-only devices exist. Supporting READ(10) but only WRITE(6) for a read/write device looking like a great strangeness to me. This should be checked for other device types... > In other words, you're just reversing the default and > the fallback positions. > > I think auto-detecting the quirk is still a good bet, > even in the 6 byte only case, just as it would have > been in the 10 byte only case. May-be just applying simple rules based on [SCSI version | SCSI plagiarism (ex: USDB, ATAPI,...)] + Device type should avoid autodetection in most situations. > Thanks for the info on what's supposed to be done going > forward, though. If there's no performance issue with > 10 byte commands, inverting the default and the quirk > handling in the failure case seems to be the right thing > to do. The performance issue is certainly negligible (~ 1 micro-second), and as I wrote above it only applies to the first GB of disks. (Additionnaly, the tranfer length is limited to 256 sectors) So, unless we want to advertise about best support for 1 GB hard disks, better not to mix disk performance issue with 6 byte command preference, in my humble opinion. :-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020207205736.W1763-100000>