> So even if you use 100% of a 256MB drive's on-board RAM as write cache, the following gigabytes of > a large metadata update won't get much benefit from caching. The drive > will be stuck a quarter gigabyte behind the host, trying to catch up > all the time. Well, at least in theory the cache should still make the drive go faster by reordering the writes to minimize seek and rotational latency. Only the drive knows its own layout and latencies, so only the drive can do this optimization. I suppose that for a long time you can assume that writes to LBAs with large absolute differences would be slower than writes to LBAs with small ones, but I'm not so sure even that's true anymore. Especially with shingled drives (though my drives are not shingled, and I know that's a whole other discussion). In any event, only the drive knows for sure. Oh, question about transaction queuing: can each transaction on the queue consist of any number of LBAs as long as they're consecutive? I am trying to figure out if 4Kn (4Kb native sectors) buys you anything over I/O on a 512e drive in multiples of 8 properly aligned LBAs. If each transaction can be of any number of LBAs, it's hard to see any real benefit to 4Kn except that it saves 3 bits in the LBA number.
