1 |
On Wed, Nov 25, 2020 at 5:54 AM Peter Humphrey <peter@××××××××××××.uk> wrote: |
2 |
> |
3 |
> > > Can you imagine an fstab with 22 partitions specified with UUIDs? |
4 |
> |
5 |
> > Can you imagine an fstab with 22 partitions? |
6 |
> |
7 |
> The NVMe drive, the main one, has 18; |
8 |
|
9 |
So, if all the partitions are on one drive and that is the only drive |
10 |
you have, there aren't many issues with using raw kernel device names |
11 |
to identify them. It isn't like a partition is just going to |
12 |
disappear. |
13 |
|
14 |
Once you have multiple disks, then UUIDs or labels become more |
15 |
important, especially with a large number. If you had a dozen disks |
16 |
with dozens of partitions and tried to use kernel device names, then |
17 |
anytime a device failed or was enumerated differently you'd have stuff |
18 |
mounted all over the place. |
19 |
|
20 |
That said, something like lvm is a good solution in almost all cases |
21 |
(or something semi-equivalent like zfs/btrfs/etc which have similar |
22 |
functionality built-in). If I had that many partitions I'd hate to |
23 |
deal with wanting to resize one, and with lvm that is pretty trivial. |
24 |
You don't need to use UUIDs with lvm - they're basically equivalent to |
25 |
labels. |
26 |
|
27 |
Now, one area I would use UUIDs is with mdadm if you're not putting |
28 |
lvm on top. I've seen mdadm arrays get renumbered and that is a mess |
29 |
if you're directly mounting them without labels or UUIDs. |
30 |
|
31 |
-- |
32 |
Rich |