On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
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.-----Original Message----- From: Austin S Hemmelgarn [mailto:ahferroin7@xxxxxxxxx] 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.
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).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.
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).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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
