linux-kernel - Re: QUEUE_FLAG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Oct 2008 10:48:59 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Alan Jenkins <aj504@...dent.cs.york.ac.uk>
Cc:	jeff@...zik.org, LKML <linux-kernel@...r.kernel.org>
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/