4 ms·

My problem is that that's a pain to type out. I've read that it's necessary (and other's have said it's not), but it'd be more convenient to just do `mirror /de

My problem is that that's a pain to type out. I've read that it's necessary (and other's have said it's not), but it'd be more convenient to just do `mirror /dev/sda /dev/sdb` than `mirror /dev/disk/by-id/ata-WDC_WDBNCE5000PNC_21365M802768 /dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_S2RANX0HA52854X`

quags 3y ago
One and done. One you type it would you can use zfs list|status from there. There is nothing wrong using sda and sdb but if you need to replace a drive In the future it’s just easier with the by-id label.
fluidcruft 3y ago
Working with drive serial numbers is great. I would ban using /dev/sda etc. Nothing like being able to read the sticker on the disk to make sure you pulled the right one. Or that "sda" is actually what you think it is when you're booted from a recovery disk.
deadbunny 3y ago
Create the pool using `/dev/sda` etc then: sudo zpool export tank sudo zpool import -d /dev/disk/by-id -aN
eitland 3y ago
the tab key is my friend here.
jlouis 3y ago
True, but in ZFS, you don't usually use these names unless you are shoving disks around. In which case it's nice to have an identity on the disk. Most of your work is a logical naming scheme on top.
phpisthebest 3y ago
Tab complete would not add that much over head in typing... I have never understood the complaint that verbosity is bad. We have systems that enable you to be both verbose and quick, win win... I believe defining a storage array based on an immutable ID to be far better than the dynamic OS Assigned ID like /dev/sda which may have a total of what 5 key strokes more when using tab complete?
tomxor 3y ago
> I've read that it's necessary (and other's have said it's not) It is not, it's outdated advice that stubbornly persists. Try it yourself if you are not convinced, create a pool using /dev/sdx and change the device order, zfs will still find it, because why wouldn't they just dereference sdx and store UUIDs?
- Filligree 3y ago
  Does that still work if you remove one device while renaming?
  - tomxor 3y ago
    Renaming pools is not related. Specifying devices to `zpool create` as path vs uuid vs partlabel vs partuuid makes absolutely no difference to the end result of what is written to the devices, and never did. ZFS does not rely on device paths to identify vdevs (that would be nuts if you consider ever trying to move pools between machines). However it used to make a difference to the /etc/zfs/zpool.cache [0] which records the current imported pools for the OS. AFAIU the problem used to be that this cache would inherit device specifications from the zpool import command (or implicit import from a zpool create command), and this is what got people got into trouble when device path enumeration is not deterministic across boots, thus the advice to avoid device paths during zpool create arose, but was only really applicable to zpool import ... This was never a permanent issue for the pool, you could always simply re-import it with UUIDs etc to rebuild the cache in a reliable way. This was patched way back in 2016, to make sure the cache never uses /dev/sdx alone... Although it's kind of buried in a commit at the end of a semi-related PR [1]: Fix 'zpool import' blkid device names When importing a pool using the blkid cache only the device node path was added to the list of known paths for a device. This results in 'zpool import' always using the sdX names in preference to the 'path' name stored in the label. To fix the issue the blkid import path has been updated to add both the 'path', 'devid', and 'devname' names from the label to known paths. Sanity check is done to ensure these paths do refer to the same device identified by blkid. You can cat your zpool.cache and see those three identifiers in the ASCII parts for yourself. TL;DR you are free to specify devices using /dev/sdx This is the same problem I mentioned in my other comment, the current quantity of ZFS myths and outdated advice on the web is substantial and takes a lot of navigating or investigating - The best you can do for now is never accept any advice without proof, and test, always test. [0] https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#the-etc-zfs-zpool-cache-file https://openzfs.github.io/openzfs-docs/Project%20and%20Commu... [1] https://github.com/openzfs/zfs/pull/4523/commits/73abf3a863499a40d9433980a9c1f906ca884c9e https://github.com/openzfs/zfs/pull/4523/commits/73abf3a8634...

quags 3y ago

One and done. One you type it would you can use zfs list|status from there. There is nothing wrong using sda and sdb but if you need to replace a drive In the future it’s just easier with the by-id label.

fluidcruft 3y ago

Working with drive serial numbers is great. I would ban using /dev/sda etc. Nothing like being able to read the sticker on the disk to make sure you pulled the right one. Or that "sda" is actually what you think it is when you're booted from a recovery disk.

deadbunny 3y ago

Create the pool using `/dev/sda` etc then: sudo zpool export tank sudo zpool import -d /dev/disk/by-id -aN

eitland 3y ago

the tab key is my friend here.

jlouis 3y ago

True, but in ZFS, you don't usually use these names unless you are shoving disks around. In which case it's nice to have an identity on the disk. Most of your work is a logical naming scheme on top.

phpisthebest 3y ago

Tab complete would not add that much over head in typing... I have never understood the complaint that verbosity is bad. We have systems that enable you to be both verbose and quick, win win... I believe defining a storage array based on an immutable ID to be far better than the dynamic OS Assigned ID like /dev/sda which may have a total of what 5 key strokes more when using tab complete?

tomxor 3y ago

> I've read that it's necessary (and other's have said it's not) It is not, it's outdated advice that stubbornly persists. Try it yourself if you are not convinced, create a pool using /dev/sdx and change the device order, zfs will still find it, because why wouldn't they just dereference sdx and store UUIDs?

Filligree 3y ago
Does that still work if you remove one device while renaming?
- tomxor 3y ago
  Renaming pools is not related. Specifying devices to `zpool create` as path vs uuid vs partlabel vs partuuid makes absolutely no difference to the end result of what is written to the devices, and never did. ZFS does not rely on device paths to identify vdevs (that would be nuts if you consider ever trying to move pools between machines). However it used to make a difference to the /etc/zfs/zpool.cache [0] which records the current imported pools for the OS. AFAIU the problem used to be that this cache would inherit device specifications from the zpool import command (or implicit import from a zpool create command), and this is what got people got into trouble when device path enumeration is not deterministic across boots, thus the advice to avoid device paths during zpool create arose, but was only really applicable to zpool import ... This was never a permanent issue for the pool, you could always simply re-import it with UUIDs etc to rebuild the cache in a reliable way. This was patched way back in 2016, to make sure the cache never uses /dev/sdx alone... Although it's kind of buried in a commit at the end of a semi-related PR [1]: Fix 'zpool import' blkid device names When importing a pool using the blkid cache only the device node path was added to the list of known paths for a device. This results in 'zpool import' always using the sdX names in preference to the 'path' name stored in the label. To fix the issue the blkid import path has been updated to add both the 'path', 'devid', and 'devname' names from the label to known paths. Sanity check is done to ensure these paths do refer to the same device identified by blkid. You can cat your zpool.cache and see those three identifiers in the ASCII parts for yourself. TL;DR you are free to specify devices using /dev/sdx This is the same problem I mentioned in my other comment, the current quantity of ZFS myths and outdated advice on the web is substantial and takes a lot of navigating or investigating - The best you can do for now is never accept any advice without proof, and test, always test. [0] https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#the-etc-zfs-zpool-cache-file https://openzfs.github.io/openzfs-docs/Project%20and%20Commu... [1] https://github.com/openzfs/zfs/pull/4523/commits/73abf3a863499a40d9433980a9c1f906ca884c9e https://github.com/openzfs/zfs/pull/4523/commits/73abf3a8634...