Messages in this thread | | | Date | Tue, 14 Oct 2008 10:48:59 +0200 | From | Jens Axboe <> | Subject | Re: QUEUE_FLAG_NONROT |
| |
On Tue, Oct 14 2008, Alan Jenkins wrote: > Jens Axboe wrote: > > On Tue, Oct 14 2008, Pierre Ossman wrote: > >> Hi Jeff, > >> > >> I noticed you've added a new flag to indicate that the drive has no > >> seek costs and I figured it would be a good idea to use that on the > >> MMC/SD cards. > > > > That was me, actually... > > > >> Since the name isn't entirely clear in what is implied, I just wanted > >> to check that there are no plans to assume that there is negligable > >> request overhead for queues with this flag. I.e. the flag should > >> indicate that the elevator doesn't have to care about seeks, but it > >> should still try to merge requests to reduce the transaction overhead. > > > > Sounds about right. The flag is just meant to indicate zero-seek cost, > > as devices will still have per-command overheads, merging is still > > applicable. > > > > So yes, you want to set that flag for mmc/sd cards, definitely. > > Is there a way for users to get / set it manually? Can hdparm / > sdparm / sg_inq tell me whether my device sets the flag... I think you > said it was word 0x217 in a recent draft, but I don't know how I could > query that as a user.
It's word 217, not 0x217 (there aren't that many words :-) hdparm can tell you full ID page, use hdparm --Istdout /dev/sdX to retrieve it.
> I'd like to know whether the SSD in my netbook provides the right flag > - and if not, set it manually, instead of having to force the noop io > scheduler.
The flag isn't currently exposed through sysfs, but it does seem like a good idea to do so.
> It might also be possible to write a udev test program, which would be > guaranteed exclusive access, to measure seek times and set the flag > appropriately. I assume we wouldn't be able to rely on USB flash > drives having the right flag set.
I'm sure that people would be pissed to have udev seeking all over the place to determine this, so I think that'd be best deferred to a manual run of some sort.
-- Jens Axboe
| |