Do you believe the drive cache problem has beeen fixed in XLD?

Reply #25 – 2008-09-16 02:18:11

Quote from: greynol on 2008-09-15 22:36:54

I wish I could give you more information, but as you have probably already noticed this is beyond my level of expertise. I'd check with Spath, Spoon or Andre.

OK, went looking... this is nothing fancier than still supporting the old 'proprietary' ways of reading CDs from waaaaay back in the day before MMC. They still support a density set followed by using Read10/12, and those commands allow an FUA bit. Unlike some drives that accept the FUA bit on the old SCSI commands and then ignore it in practice, I've verified that the Plextors here are, in fact, obeying the bit. Hooray command set throwbacks to 1994! It's actually kinda neat.

However, it's having a very unexpected effect; rather than allowing the drive to use the readahead cache intelligently (using the cache to speed internal operation and dumping the cache on nonlinear access) it appears to be completely disabling all readahead caching even for internal operations. That's.... taking things just a bit too literally! It really cripples the drive's performance.

So Plextor offers two options, both of them kinda stupid. They could give both sides what they really want by simply flushing cache on nonmonotonic access, the only thing thatreally makes any sense on audio, but that's not an option. Ahh, ain't that the way in computers these days.

Oooh, I wonder what happens if you *mix* the command sets... I sense a bricked drive coming right up... ;-)

[Oh, and you also prompted me such that I ran across a remaining bug in the 15-year-old-command set support, so this has been a most fruitful line of inquiry! FWIW, it doesn't affect ripping much, it just throws a spurious SCSI error at the start]