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

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]