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

1 Answer 1


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() Jan 19, 2018 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, 2018 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 Jan 24, 2018 at 12:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .