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

Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> · Tue, 8 Sep 2015 08:56:08 -0400

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.

Attachment:
smime.p7s

Description: S/MIME Cryptographic Signature