Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device

[Austin S Hemmelgarn]

On 2015-09-06 13:51, Elliott, Robert (Persistent Memory) wrote:

mkfs.btrfs does not detect pmem devices as being SSDs in kernel 4.2.

Label:              (null)
UUID:               46603efe-728c-43fe-8241-ffc125e1a7ed
Node size:          16384
Sector size:        4096
Filesystem size:    8.00GiB
Block group profiles:
   Data:             single            8.00MiB
   Metadata:         DUP             417.56MiB
   System:           DUP              12.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
    ID        SIZE  PATH
     1     8.00GiB  /dev/pmem0

mkfs.btrfs opens "/sys/block/%s/queue/rotational" and looks for
0 (non-rotational - an SSD) or non-zero (rotational - a HDD).

While not directly related in this case, it's worth pointing out that there are lots of things that are not SSD's that get listed as non-rotational by default (and you can in fact change the value of this file from userspace), such as: virtualized block storage (xvdb and virtio at least, not sure about vmware or hyperv), and some networked block devices (NBD may or may not, depends on server side configuration, ATAoE did at least at one point, RBD gets listed as non-rotational, DRBD tracks underlying storage on the local node).

However, strace shows it is having trouble creating that path.
The blkid_devno_to_wholedisk function from libblkid leads it to
this path:
        /sys/block/LNXSY/queue/rotational
which doesn't exist.

That is based on:
$ realpath /sys/block/pmem0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus1/region0/namespace0.0/block/pmem0

$ realpath /sys/dev/block/259:0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus1/region0/namespace0.0/block/pmem0

The impact looks limited to the print and causing it to not
automatically disable "metadata duplication on a single device."

This is an issue inherent in the current pmem driver however, it should be fixed there and not in mkfs.btrfs, as other filesystems make decisions based on this file also, as does the I/O scheduler, and some block storage servers. This gets tricky though because pmem isn't technically a block device at the low level, and doesn't use some parts of the block layer that most other block devices do.

On that note however, if the pmem device is backed by actual RAM and not flash storage (and most of them are from what I've seen), then the only advantage of using single metadata mode over dup is space savings, as RAM is not (usually) write limited.

smime.p7s
Description: S/MIME Cryptographic Signature