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

[Austin S Hemmelgarn]

On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:

-----Original Message-----
From: Austin S Hemmelgarn [mailto:ahferro...@gmail.com]
Sent: Tuesday, September 8, 2015 7:56 AM
Subject: Re: mkfs.btrfs cannot find rotational file for SSD detection for
a pmem device

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

...

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.
...

The rotational file does exist, at:
/sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/ACPI0012\:00/ndbus1/region0/namespace0.0/block/pmem0/queue/rotational

One or more functions are having trouble parsing that 108-byte string
... mkfs.btrfs's is_ssd, libblkid's blkid_devno_to_wholedisk, or
libblkid's sysfs_devno_to_wholedisk.  I'm not sure where the
breakdown occurs.

Ah, sorry about the confusion, I didn't think to actually look before commenting. So, it looks like this amounts to some short-sighted coding, although I could see why they wouldn't have accounted for the possibility of having to parse some monstrous path like that, and that also would explain why kernel side stuff isn't choking on it. Now, the real question is why we have to go through the full absolute path in sysfs, and can't just go through /sys/block/pmem0.

This is reminiscent of an issue that numactl has parsing the path to
get to .../device/numa_node (rather than .../queue/rotational).  It
was confused by not finding "/devices/pci" in a path for a storage
device.

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.

pmem devices will be a mix ranging from flash-backed DRAM to new
technologies like 3D Crosspoint, usually offering high performance
and good wearout characteristics.

Hmm, I've never actually seen flash-backed DRAM based NV-DIMM's, although I've not necessarily been keeping up to date. Most of what I've seen have been small (512M or 1G) ferro-electric RAM based ones, and an early design that was battery backed (which is just a crisis waiting to happen).

The btrfs driver does detect it as SSD after mkfs.btrfs did not:
kernel: BTRFS info (device pmem0): disk space caching is enabled
kernel: BTRFS: has skinny extents
kernel: BTRFS: flagging fs with big metadata feature
kernel: BTRFS: detected SSD devices, enabling SSD mode

That makes sense if it's an issue in userspace with parsing of the path, although depending on the actual underlying storage for the pmem device, this may actually make things slower (the particular effect of SSD mode is that it tries to spread allocations out as much as possible, as this helps with wear-leveling on many SSD's).

smime.p7s
Description: S/MIME Cryptographic Signature