Hacker News Reader

Comment by m463 | Hacker News Reader

I just recently read through this and it's a goldmine of hard-won information big and small, like ventoy or mounting disks using /dev/disk/by-id/

View on HN

While playing with NixOS the other day I learned about /dev/disk/by-label which is the equivalent, but works with partition labels. So much more elegant than /dev/sda2.

Or mount -L and LABEL=... in fstab

They're filesystem labels. /dev/disk/by-label gets populated by udev [0]. The labels can be set with "e2label", "btrfs filesystem label", or other tools depending on the filesystem type.

[0] https://github.com/systemd/systemd/blob/master/rules.d/60-pe...

Old-time Linuxer here but it's the first time I heard of either Ventoy, MergerFS or SnapRAID.

Sounds like using mergerfs together with snapraid would work similar to the popular Unraid software but more diy.

Unraid provides real time data protection, whereas Snapraid with mergerfs provide disk pooling and scheduled snapshots. That's its greatest feature IMO - expandability and data protection without rigid expansion requirements.

AFAIK, it's one of a kind. Flexraid on Windows was the closest I had found (a product I still use on an old install - software and owner disappeared - although I did manage to track down the patent and the developer once, seems to have moved on to other interests/employment)

Ventoy is relatively new bootable USB creator supporting booting directly from ISOs instead of actually block by block copying (old fashioned - like dd or pv, quite like it). It works very well in most cases using popular distros, a bit glitchy on Macs LoL

I'm sure there's a reason mounting by ID isn't the default but that's always been a weird one for me and I make sure to swap it over when building a storage server.

It's usually the default in /etc/fstab for most distributions.

It's often simpler to just mount /dev/sda if you just connected it and need to do a one-off. But if you want something reliable, for automount for instance, I don't see why anyone would use something else than UUIDs. I even put those on stickers on my external hard drives.

Another tip I like is using noauto,x-systemd.automount to mount on-demand, and unmount after a set inactivity timer: https://www.freedesktop.org/software/systemd/man/systemd.mou...

I don't see why anyone would use something else than UUIDs

Some partitions don't have UUIDs, such as LUKS volumes with a detached header or plain dm-crypt volumes. In that case, I use a /by-id/wwn-* path to uniquely identify the partition. Of course, those lines are in /etc/crypttab, not in /etc/fstab.

OK, I re-read the thread, and noticed where the confusion comes from.

https://wiki.archlinux.org/index.php/Persistent_block_device...

I am talking about UUIDs, that basically any (Linux at least) filesystem has. Those are a bit like filesystem labels, but generated during filesystem creation. Their format makes collisions virtually impossible. LUKS volumes have one, and partitions inside them have a different one too.

This is my prefered way of identifying partitions, as they are persistent even when you move them around with lvm, dd, or others. I think that's also the default in many distributions.

PARTUUID is also a nice way to identify partitions when you can't rely on a partition UUID for some reason. It works like UUIDs, but instead of being stored inside the partition, that information is part of the GPT (GUID partition table).

If you are more interested in the drives than the partition content, by-id makes sense, though I think the use-case is rather narrow :)

with /dev/disk/by-id you get a unique name for the physical hardware. like /dev/disk/by-id/ata-Samsund_SSD_blah...<serialno>

uuid is different but you can access it with /dev/disk/by-uuid

"I even put those {UUIDs} on stickers on my external hard drives."

That's pure genius. Gonna steal that idea outright. LOL - I'ma go even one step further in my own personal setup, and encode it into a QR code sticker so I can just snap it right into my clipboard from KDE Connect on mah phone when I need to. ;)

TBH, I just handwrote those. Just like with git, the collisions are highly unlikely, and most of the time the first few letters are all that's needed before you can tab-complete.

QR codes aren't a bad idea, but clipboard sync doesn't work quite well on wlroots-based compositors in my experience :)

Just make sure to put a bit of ASCII below your QR code.

/dev/disk/by-id is different than /dev/disk/by-uuid

for example, you dd a disk and by-uuid is ambiguous.

meanwhile by-id still finds the original disk

Reply on news.ycombinator.com