sg3_utils
sg3_utils copied to clipboard
Does REQUEST SENSE through sg_raw spin up SAS drive in powered off state?
I do not think this is an issue but I wanted to get some information why SAS drives in powered off state are getting spun up when issuing REQUEST SENSE through sg_raw.
Here is want I found during my investigation:
-
Issue sg_start to spin down a SAS drive: [root@sc-lab-kariraad-linux86 ~]# sg_start -v --stop /dev/sdc Start stop unit command: 1b 00 00 00 00 00
-
Issue REQUEST SENSE using sg_raw: I was expecting the drive to return a check condition with ASC/ASCQ as 0x4/0x2 [root@sc-lab-kariraad-linux86 ~]# sg_raw -v -r 32 /dev/sdc 03 00 00 00 FC 00 cdb to send: 03 00 00 00 fc 00 SCSI Status: Good
Received 32 bytes of data: 00 70 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 p............... 10 00 00 95 46 3b 00 00 00 38 2a 95 46 3b 00 00 00 ...F;...8*.F;... No errors
-
In the dmesg log I found the following prints: [root@sc-lab-kariraad-linux86 ~]# dmesg | grep sdc sdc: Spinning up disk....<7>pdflush(438): WRITE block 477626552 on dm-0 sdc : very big device. try to use READ CAPACITY(16). SCSI device sdc: 7814037168 512-byte hdwr sectors (4000787 MB) sdc: Write Protect is off sdc: Mode Sense: db 00 10 08 SCSI device sdc: drive cache: write back w/ FUA sdc : very big device. try to use READ CAPACITY(16). SCSI device sdc: 7814037168 512-byte hdwr sectors (4000787 MB) sdc: Write Protect is off sdc: Mode Sense: db 00 10 08 SCSI device sdc: drive cache: write back w/ FUA sdc:<7>sg_raw(10526): READ block 0 on sdc sg_raw(10526): READ block 8 on sdc sg_raw(10526): READ block 16 on sdc sg_raw(10526): READ block 24 on sdc sg_raw(10526): READ block 32 on sdc sg_raw(10526): READ block 7814037160 on sdc sg_raw(10526): READ block 7814037128 on sdc sg_raw(10526): READ block 7814037136 on sdc sg_raw(10526): READ block 7814037144 on sdc sg_raw(10526): READ block 7814037152 on sdc sdc1 sdc2 sdc3
-
I do not see the drive spinning up when I force the drive into one of the power condition states. In the example below I am forcing the drive to enter STANDBY_Y [root@sc-lab-kariraad-linux86 ~]# sg_start -p 3 -m 1 -v /dev/sdc Start stop unit command: 1b 00 00 01 30 00
[root@sc-lab-kariraad-linux86 ~]# sg_raw -v -r 32 /dev/sdc 03 00 00 00 FC 00 cdb to send: 03 00 00 00 fc 00 SCSI Status: Good
Received 32 bytes of data: 00 70 00 00 00 00 00 00 0a 00 00 00 00 5e 0a 00 00 p...........^... 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ No errors
I would really appreciate your thoughts on this.
Advice: to have the least number of side effects in the Linux SCSI pass-through use either /dev/sg* or /dev/bsg* device. IOW unhelpful things can happen when you use a block layer device (e.g. /dev/sdc) such as you describe. It makes no difference whether you use sg_raw or sg_requests to send a REQUEST SENSE. If a disk is spun down and you send a REQUEST SENSE to the corresponding block device (e.g. /dev/sdc) then the !@#$ing stupid block layer will insert a START STOP UNIT(start) command before (or after, I'm not sure) that REQUEST SENSE. Isn't that clever!
Sense condition is one-shot; as soon as someone reads it they are gone. In your case the sense condition will be eaten up by the kernel, as you're spinning up the drive and the kernel does additional action on that drive.