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: 3428 bytes --]

On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
>
>> -----Original Message-----
>> From: Austin S Hemmelgarn [mailto:ahferroin7@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).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]