3

Run dmesg and grep on [sda] Mode Sense: to return a row such as this:

[sda] Mode Sense: 00 3a 00 00

What do the 4 bytes of data represent 00 3a 00 00?

Its likely the answer is contained in a subsequent row of output such as:

[sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

... but I would like to know how to map the data to the descriptions

5

They are the first four bytes in the buffer returned from a mode sense command (see drivers/scsi/sd.c, sd_mode_sense()). The meaning can be gleaned by looking at drivers/scsi/scsi_lib.c, scsi_mode_sense()): this routine returns a structure called "data" which, according to a comment, abstracts the mode header data; the first two bytes in the buffer (00 and 3a) are the high order/low order bytes of the length of "data" minus 2, the third byte (00) is the medium_type, and the fourth byte is device-specific:

        data->length = buffer[0]*256 + buffer[1] + 2;
        data->medium_type = buffer[2];
        data->device_specific = buffer[3];

So data->length is 0*256 + 0x3a + 2 = 60, the medium_type is 0 and who knows what the fourth byte means... (BTW, the printk that prints that Mode Sense: line is labeled KERN_DEBUG so it's really not meant for regular consumption).

You can use sg_modes from the sg3_utils package to examine things like this without having to go to extreme lengths to translate them:

 # sg_modes -a /dev/sg0
    ATA       SAMSUNG MZ7LN512  4L0Q   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
  Mode data length=60, medium type=0x00, WP=0, DpoFua=0, longlba=0
  Block descriptor length=8
> Direct access device block descriptors:
   Density code=0x0
 00     00 00 00 00 00 00 02 00

>> Read-Write error recovery, page_control: current
 00     01 0a 80 00 00 00 00 00  00 00 00 00
>> Caching, page_control: current
 00     08 12 04 00 00 00 00 00  00 00 00 00 00 00 00 00
 10     00 00 00 00
>> Control, page_control: current
 00     0a 0a 02 00 00 00 00 00  ff ff 00 1e

The other line you mention:

Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

is produced by the routine sd_read_cache_type in drivers/scsi/sd.c. It uses a couple of different sources for that information: the write and read cache information is obtained by looking at a specific byte of the modepage==8 buffer; the DPO/FUA information is obtained from the abovementioned "data" structure (although it does not necessarily contain the same data: the modepages used in the two calls may be different).

AFAICT, the information on this line and the information on the debugging line above are not directly related.

  • sd_mode_sense() in line two of your answer should be scsi_mode_sense() – Justchoose1 Jan 19 '18 at 10:12
  • Maybe, but it makes very little difference, if any: the message itself is printed by sd_read_write_protect_flag() which calls sd_mode_sense(). But this is a very short inline function that just calls scsi_mode_sense() and returns the result. – NickD Jan 22 '18 at 0:52
  • I only mentioned it so that the answer could be edited so as not to confuse others who reference it - many thanks for your time and thorough answer – Justchoose1 Jan 24 '18 at 12:57

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.