2

I'm trying to optimize the IO schedulers and to use a proper scheduler for rotational and for non rotational drives (different). When I run:

cat /sys/block/sd*/queue/rotational

I get:

1    <-- for sda
1    <-- for sdb

although sdb is the usb flash drive and it shouldn't be rotational.

$ udevadm info -a -n /dev/sda | grep queue
ATTRS{queue_depth}=="31"
ATTRS{queue_ramp_up_period}=="120000"
ATTRS{queue_type}=="simple"

$ udevadm info -a -n /dev/sdb | grep queue
ATTRS{queue_depth}=="1"
ATTRS{queue_type}=="none"

so there is no such attribute as:

ATTR{queue/rotational}=="0" or ...=="1"

2 Answers 2

1

Yes it's a wired and confusing issue; here's the corresponding kernel bug 90761 (reported 2015) and a 2019 blog post investigating this. Presumably, it's just a cosmetic issue, as the traditional IO-schedulers have all been superseded by mq-deadline.. However, with considerable head-scratching, I came up with an applicable rule, so I thought I might just as well post it here.

/etc/udev/rules.d/usb-flash-drive-non-rotational.rules:

# Try to catch USB flash drives and set them as non-rotational. Probably no impact whatsoever : /
# c.f. https://mpdesouza.com/blog/kernel-adventures-are-usb-sticks-rotational-devices/

# Device is already marked as non-rotational, skip over it
ATTR{queue/rotational}=="0", GOTO="skip"

# Device has some sort of queue support, likely to be an HDD actually
ATTRS{queue_type}!="none", GOTO="skip"

# Flip the rotational bit on this removable device and give audible signs of having caught a match
ATTR{removable}=="1", SUBSYSTEM=="block", SUBSYSTEMS=="usb", ACTION=="add", ATTR{queue/rotational}="0"
ATTR{removable}=="1", SUBSYSTEM=="block", SUBSYSTEMS=="usb", ACTION=="add", RUN+="/bin/beep -f 70 -r 2"

LABEL="skip"
1

You can run hdparm -I for each of your disks:

hdparm -I /dev/sda
hdparm -I /dev/sdb

If the output of the hdparm -I line includes a line like:

Nominal Media Rotation Rate: Solid State Device

that would indicate the drive is non-rotational, using information from ATA-style IDENTIFY response.

But apparently there is another way to query this information too, and the kernel seems to prefer it. If you have the sg3_utils package installed, you could use this command to make a query that is identical to what the kernel does (at the time of this writing at least):

sg_inq --vpd --page=0xb1 /dev/sda

If the response includes the line:

Non-rotating medium (e.g. solid state)

...then, and only then will the /sys/block/sd*/queue/rotational attribute be set to 0.

If your USB flash drive is USB2, any scheduler-based optimizations are likely going to be overwhelmed by the USB protocol inefficiency. Only worry about this if you have an actual USB3 SuperSpeed drive.

4
  • Unclear: I have an USB3 SSD drive, with hdparm -I giving Nominal Media Rotation Rate: Solid State Device AND /sys/block/.../queue/rotational set to 1.
    – Bruno
    Jul 17 at 14:59
  • @Bruno Hmm... looks like hdparm -I uses ATA-style IDENTIFY data, while the kernel /dev/sd* driver seems to prefer SCSI-style VPD data pages. sg_inq --vpd --page=0xb1 /dev/sdX could be used to query the drive the exact same way as the kernel apparently does. Of course whenever there are two possible ways to report some information, there is a manufacturer that doesn't take care to have both ways report the same data... :-(
    – telcoM
    Jul 17 at 15:42
  • the page 0xb1 is out of domain. The supported pages are 00, 80, 83, b0, b2, de, df... Whatever, it works, and I don't care the performance on that drive. This is a git/backup/auth/db/web/etc... server on a Raspberry, which is used by myself only (with some visits from search engines and ssh hackers ;-)
    – Bruno
    Jul 18 at 17:06
  • @Bruno Interesting. My Samsung SSD 850 Pro both lists VPD page 0xb1 as supported on VPD page 00, and actually provides page 0xb1 when queried. Would not be the first time when manufacturers interpret specifications loosely, perhaps...
    – telcoM
    Jul 18 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy