Re: QUEUE_FLAG_NONROT

[Jens Axboe <jens.axboe@oracle.com>]

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