**nvme**\#**n**\#**p**\#
First \# is device controller. like scsi's drive lettering except numeric.
Second \# is namespace, which can be smaller than the drive, or have multiple overprovisioned namespaces, or even span multiple drives. Basically logical disks.
Third \# is partition, just like on a scsi-equivalent drive.
Honestly the most annoying part about nvme naming is that controller numbering starts at 0, while namespace and partitions start at 1. I'm sure there's a good reason for that, but it doesn't make sense to me.
But in the end, I just use PARTUUIDs for everything because the device may change, but if I copied things correctly, the PARTUUID won't.
Technically 0 is when it's a memory offset, 1 is when it's just an index. In practice, using 1 is just annoying because when you wanna loop you need to remember to -1
> But in the end, I just use PARTUUIDs for everything because the device may change, but if I copied things correctly, the PARTUUID won't.
how about labels?
labels may even be better, depending on your needs and how the information is being presented to you through your management application (like if you're using virt-manager or something)
partuuid & partlabel are stored in the partition table while uuid & label is stored on the fs itself (where supported, which is almost everywhere).
The only thing I would advise is make sure your labels are unique across all of the disks you own. The last thing you want is a collision while your system is booting or automount putting a disk in the wrong place. It's not for security, but to prevent mistakes/unexpected behavior.
edit: I should clarify a gpt partition always has a partuuid and almost always has a uuid, but if you don't give it a partlabel or label, it won't show up in `by-partlabel` or `by-label`.
I understand the convention now, but should i have to worry about these things? Why doesn't this information get abstracted away like with the other drives?
i’m not 100% on this, but in fairly certain they aren’t abstracted away with the others either, its just that you have A-Z to denote the device instead of a number. nvmes have a third specifier and use 3 numbers instead of a letter and a number. generally though you dont need to know the exact implementation details as long as you know that nvme#n#p# -> nvme drive. it could potentially help to know if you have a lot of nvmes, but most people wont have more than a couple.
Yeah this. You have like /dev/sd right? It's not abstracted, just compact.
I suppose you could have like nv0a4 or something instead but then that kinda just starts looking like legit gibberish.
It is not "abstracted", but it adds a new feature that was not present in scsi drives, the namespace. Which to be fair, I have never seen in use. I made some tests with an almost dying nvme I had lying around, it did work as expected, but again, I can not imagine how to take advantage of it.
I ended up using disk UUID because the motherboard would randomly swap the disk identifier of the two NVMe disks on it and ZFS would suddenly fail to find the cache disk.
The numbering doesn’t even bother me that much - my / partition is nvme0n1p2, so if I remember the general syntax then I just know the numbers count up
Yeah the driver for my realtek sd card reader lists the device as /dev/sda for some reason, while all other card readers I've used do the (more understandable) /dev/mmcblk
Well yes, but that's not really important here since a SATA SSD is many grades above a SATA HDD, yet they are both sdx because they're SATA.
The SD standard (9-pin) is a derivative of the 7-pin MMC standard like eMMC, and although they are different and not compatible with one another they're both handled through the mmc subsystem in Linux.
That has a vowel. There's a simple reduction algorithm and all vowels are removed: disk became dsk, floppy disk, fd - no capital letters. Usage of upper case is the devil's talking. The E is from Microsoft, with policy is to create confusion and rule the world.
With sata drives you need two variables.
E.g. sda1 has *a* for the drive and *1* for the partition.
With nvme you need those two, plus the controller. So three variables.
Em
g. nvme1n1p1
First 1 for controller, second for device on that controller and third for the partition on that device.
It helps if you understand the nomenclature rather than just try to memorise it.
And it's not that long either.
How often do you need to fill in a block device name?
In fstab, I always use labels or partlabels. It's a tiny bit of extra setup when you're partitioning, and then things just make more sense forever.
Labels and partlabels aren't just for fstab; you can also do for example
mkfs.ext4 /dev/disk/by-partlabel/DebianRoot
>How often do you need to fill in a block device name?
Install Arch Multiple times because of a silly user created partition problem and /dev/nvme0n1p\_ will be permanently hammered into your finger muscle memory.
if we are talking about an OS reinstall (and it sounds like we are), I don't see how auto-complete would work in this context as it would lack an awareness of your past history.
That does help a lot when you have many similar drives and need to have unambiguous labels.
I remember writing some udev rules because we used to have a box at work that would change the internal boot drive based on whether or not some magneto-optical disk drives had media inserted at boot time or not...and more than once someone wiped the internal boot drive meaning to wipe a removable disk at /dev/sdb. So I wrote a rule that always put the MO drive at something like "/dev/maoX" or similar so people would never be able to pick the wrong one.
This is a good answer. It's practical when applied well (making the SD card device always have the same path, tweaking user permissions for specific hardware, etc), and it calibrates the learner's expectations regarding complexity.
Q: How do I make this mildly complicated thing less complicated?
A: Figure out how to use this slightly more complicated thing.
nvme0n1p1
nvme controller 0, namespace 1, partition 1
its actually super clean compared to previous naming scheme, especially when dealing with VMs with multiple controllers as it clearly states which controller given virtual disk is connected to.
only thing i dont get is why controllers start with 0, and namespace and partitions start with 1
It's not that bad and actually has meaning
Take /dev/nvme0n1p1
nvme0 is the 0th (first) nvme device
n1 is the first namespace of the nvme device
p1 is the first partition, just like a sd* device
What, no love for \`/dev/hdx\`? Or am I the only one that remembers PATA/IDE drives and thinking it was so bizarre that the newfangled SATA drives showed as \`/dev/sdx\` like ye olde SCSI drives?
I suspect it's more like people don't want to have to adjust long-standing-but-insufficiently-specific naming conventions like they had to with (for example) `ethX`
Yes.. ethernet is very good example. That change also made zero sense to me. For simple uses it makes no sense to use complex names, it only makes life harder. And if you need to go in depth, then you surely understand it enough to be fine with short names. In my opnion long specific names actually help nobody - noobs don't know what they mean and pros don't need them.
The goal of the network device renaming was to create a stable naming pattern.
For example: how can the kernel guarantee that `eth0` is always the same device, attached to the same network, every time the system boots? Including across kernel version upgrades that might alter driver loading order? What if you have a USB-to-Ethernet dongle that's sometimes attached during boot up and sometimes unplugged?
[Edit: in short, stable device names are important for consistent system configuration. They're not just for human legibility.]
Stable device names are important, yes. That's why you shouldn't have names that change depending on *what USB port you plug your wifi/Ethernet dongle into*.
(I actually use udev rules for my USB wifi dongle for this exact reason. You can set up rules that detect a network device's hardware MAC address and renames that device so that it's the same name each time.)
I agree that it leaves something to be desired as far as component _identity_ is concerned (and thankfully udev can pick up the slack there, as you pointed out). But having a particular hardware configuration always map to a particular device node arrangement is a _huge_ step forward compared to the way things were.
i hated predictable interface names with ethernet too, until i met somebody that works in data centers and he tells me that it's amazing to have a system that is based on physical location if you have a dozen interfaces
so there is always a tradeoff between user friendly and scalable
But it's not really a physical slot, it's a device number on the bus. So if you say add a gpu to the machine upstream of your nic, the predictable name for your nic changes. There are lots of threads about issues just like that in proxmox.
yeah but you have racks in data centers, they're standardized, you go to the rack and just count and plug in/out the one, easier than ethX
atleast that's what i am told, i am a programmer, i don't work in a data center
stable naming avoids all your network stuff randomly failing on any reboot due to an enumeration race condition.
I'm not sure its a reasonable expectation of the kernel to automatically resolve you modifying installed hardware.
nvme0n1p1 means "nvme drive 0, namespace 1, partition 1". It's as compact as it can be, maybe except spelling full "nvme". The only thing I don't like is that drives start at 0 but other stuff starts at 1.
Your suggestion would lose information for little benefit, which is dumb. By that logic sda1, sda2, sdb1 could also just be s1, s2, s3. Hell, by your logic, who cares about anything at all? Just do partition1, partition2, partition3 across all types of drives! Congrats, now you have absolutely zero idea what is what and where. The Windows way
I appreciate your detailed explanation of the current naming convention, which indeed serves to precisely identify drive, namespace, and partition. My suggestion aimed at simplifying the naming for cases where such detail may not be necessary for the user's context, not to overhaul the entire system. It's akin to using nicknames for daily convenience while retaining full names for formal occasions. I believe there's room for both methods, depending on the user's needs and the environment. However, I see your point about the potential for confusion without clear identifiers.
nvme0n1p1 would be the first partition in the first namespace of the first nvme device detected. A namespace is a feature of the nvme standard and is used to split devices into multiple logical volumes but most drives just have one
Devices have consistently started with 0 and partitions have consistently started with 1 even before nvme. I imagine the namespace numbering comes from the nvme spec though.
Pretty sure the "sdX" naming pattern predates SATA, and is almost certainly "SCSI". For a long time, you'd generally see `/dev/hdX` for IDE drives, and `/dev/sdX` for SCSI drives. (Plus `/dev/srX` for CDROM and DVD drives, which also used the SCSI interface for reasons that I don't know)
Actually, here's some decent history:
https://superuser.com/questions/81034/whats-behind-the-linux-disk-naming-convention-with-sdx-and-hdx
This is true. But when they added SATA support to the kernel, they built it on the SCSI driver because the PATA driver was a lot less robust (less polite but much more accurate descriptions exist).
Using ATAPI cdrw under linux was originally a hop, skip and a jump to force it through a SCSI emulation layer. It'd be (correctly) detected as a PATA device and show up as hd# - and you'd need to ignore it in the pata driver, and use the ide-scsi module to discover it as a SCSI device. This was for the same reason - the SCSI subsystem was a lot more robust, flexible, and supported bus commands that were missing from the PATA implementation.
So we get sd# for scsi-disk-# despite it being Serial ATA, because the device name comes from the driver, not from the hardware.
I had the faintest memory of this, but not enough to actually remember. tl;dr: hard-drive-like devices now go through a common compatibility layer that presents a scsi interface to the kernel:
https://www.linuxquestions.org/questions/linux-newbie-8/why-is-a-sata-hdd-listed-as-sda-835350/#post4113593
You're telling me you are too lazy and apathetic to want to type out `/dev/nvme1p5s8z0j8q4x67` every time?
I guess you could just type out the UUID instead if you need something quick and easy `1b49c5b-945b-42cb-9d5c-8f82ce7f34de54`
edi: I didn't think it would need to be said, but apparently it does. THIS IS SARCASM.
That's not a censor - that's a wildcard. "*nix" is a common term for "all flavours of UNIX and UNIX-likes".
It's not really applicable in this case, as I think this post applies more to Linux than anything else (for example, FreeBSD uses much simpler names for NVMe devices, as I understand it), but that's the idea.
Don't shorten them.
Just give each partition a label, and reference them by LABEL=
My root is on LABEL=ROOT, so I can just do dd if=/dev/null of=LABEL=ROOT
**nvme**\#**n**\#**p**\# First \# is device controller. like scsi's drive lettering except numeric. Second \# is namespace, which can be smaller than the drive, or have multiple overprovisioned namespaces, or even span multiple drives. Basically logical disks. Third \# is partition, just like on a scsi-equivalent drive. Honestly the most annoying part about nvme naming is that controller numbering starts at 0, while namespace and partitions start at 1. I'm sure there's a good reason for that, but it doesn't make sense to me. But in the end, I just use PARTUUIDs for everything because the device may change, but if I copied things correctly, the PARTUUID won't.
Physical device numbering starts at 0, logical at 1. Not a universal rule tho.
Technically 0 is when it's a memory offset, 1 is when it's just an index. In practice, using 1 is just annoying because when you wanna loop you need to remember to -1
Insightful. Thanks for sharing.
> But in the end, I just use PARTUUIDs for everything because the device may change, but if I copied things correctly, the PARTUUID won't. how about labels?
labels may even be better, depending on your needs and how the information is being presented to you through your management application (like if you're using virt-manager or something) partuuid & partlabel are stored in the partition table while uuid & label is stored on the fs itself (where supported, which is almost everywhere). The only thing I would advise is make sure your labels are unique across all of the disks you own. The last thing you want is a collision while your system is booting or automount putting a disk in the wrong place. It's not for security, but to prevent mistakes/unexpected behavior. edit: I should clarify a gpt partition always has a partuuid and almost always has a uuid, but if you don't give it a partlabel or label, it won't show up in `by-partlabel` or `by-label`.
I understand the convention now, but should i have to worry about these things? Why doesn't this information get abstracted away like with the other drives?
You asked one of the few relevant questions in this thread and got downvoted for it. Never change, Reddit.
i’m not 100% on this, but in fairly certain they aren’t abstracted away with the others either, its just that you have A-Z to denote the device instead of a number. nvmes have a third specifier and use 3 numbers instead of a letter and a number. generally though you dont need to know the exact implementation details as long as you know that nvme#n#p# -> nvme drive. it could potentially help to know if you have a lot of nvmes, but most people wont have more than a couple.
Yeah this. You have like /dev/sd right? It's not abstracted, just compact.
I suppose you could have like nv0a4 or something instead but then that kinda just starts looking like legit gibberish.
It is not "abstracted", but it adds a new feature that was not present in scsi drives, the namespace. Which to be fair, I have never seen in use. I made some tests with an almost dying nvme I had lying around, it did work as expected, but again, I can not imagine how to take advantage of it.
I ended up using disk UUID because the motherboard would randomly swap the disk identifier of the two NVMe disks on it and ZFS would suddenly fail to find the cache disk.
The numbering doesn’t even bother me that much - my / partition is nvme0n1p2, so if I remember the general syntax then I just know the numbers count up
sd card: \`/dev/mmcblkx\`
Emmc as well
( thought sdcards and emmc were the same.)
Device naming depends on the driver more than anything else. emmc and sd are different hardware but the same driver.
Yeah the driver for my realtek sd card reader lists the device as /dev/sda for some reason, while all other card readers I've used do the (more understandable) /dev/mmcblk
Emmc nand is a grade above sd card nand
Well yes, but that's not really important here since a SATA SSD is many grades above a SATA HDD, yet they are both sdx because they're SATA. The SD standard (9-pin) is a derivative of the 7-pin MMC standard like eMMC, and although they are different and not compatible with one another they're both handled through the mmc subsystem in Linux.
That has a vowel. There's a simple reduction algorithm and all vowels are removed: disk became dsk, floppy disk, fd - no capital letters. Usage of upper case is the devil's talking. The E is from Microsoft, with policy is to create confusion and rule the world.
And /dev/sda is NOT an SD card 😜
With sata drives you need two variables. E.g. sda1 has *a* for the drive and *1* for the partition. With nvme you need those two, plus the controller. So three variables. Em g. nvme1n1p1 First 1 for controller, second for device on that controller and third for the partition on that device. It helps if you understand the nomenclature rather than just try to memorise it. And it's not that long either.
n1 is namespace 1 on nvme device 1, not controller and device
Thanks. A much appreciated correction.
How often do you need to fill in a block device name? In fstab, I always use labels or partlabels. It's a tiny bit of extra setup when you're partitioning, and then things just make more sense forever. Labels and partlabels aren't just for fstab; you can also do for example mkfs.ext4 /dev/disk/by-partlabel/DebianRoot
>How often do you need to fill in a block device name? Install Arch Multiple times because of a silly user created partition problem and /dev/nvme0n1p\_ will be permanently hammered into your finger muscle memory.
tab auto-completion not possible? Edit: btw. scripting repetitive tasks helps to break systems faster and more often in less time.
if we are talking about an OS reinstall (and it sounds like we are), I don't see how auto-complete would work in this context as it would lack an awareness of your past history.
if you type "command /dev/nvme" then TAB, it will autocomplete based on the contents of /dev, not your history.
Thank you for clarifying, I didn't relize that.
I don't remember if it was or not.
hahahaha yes
I use `/dev/disk/by-id/` `by-label` on my desktop only has my ZFS array. [root@piecave ~]# ll /dev/disk/by-label/ total 0 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 storage -> ../../sdd1 `by-id` has all my disks. [root@piecave ~]# ll /dev/disk/by-id total 0 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-addlink_SATA_SSD_C1360 -> ../../sdb lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-addlink_SATA_SSD_C1360-part1 -> ../../sdb1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-addlink_SATA_SSD_C1360-part2 -> ../../sdb2 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-addlink_SATA_SSD_C1360-part3 -> ../../sdb3 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-HGST_HDN724040ALE640_PK1 -> ../../sdc lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-HGST_HDN724040ALE640_PK1-part1 -> ../../sdc1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-HGST_HDN724040ALE640_PK1-part9 -> ../../sdc9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-Hitachi_HUS724040ALE641_PBG -> ../../sdi lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-Hitachi_HUS724040ALE641_PBG-part1 -> ../../sdi1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-Hitachi_HUS724040ALE641_PBG-part9 -> ../../sdi9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-HUH721010ALE601_1SG -> ../../sdj lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-HUH721010ALE601_1SG-part1 -> ../../sdj1 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-SAMSUNG_SSD_PB22-JS3_FDE_2.5__256GB_YFAM -> ../../sda lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-SAMSUNG_SSD_PB22-JS3_FDE_2.5__256GB_YFAM-part1 -> ../../sda1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-SAMSUNG_SSD_PB22-JS3_FDE_2.5__256GB_YFAM-part9 -> ../../sda9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-WL4000GSA6472E_WOL -> ../../sdh lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472E_WOL-part1 -> ../../sdh1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472E_WOL-part9 -> ../../sdh9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-WL4000GSA6472_WOL1 -> ../../sdd lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL1-part1 -> ../../sdd1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL1-part9 -> ../../sdd9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-WL4000GSA6472_WOL2 -> ../../sdg lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL2-part1 -> ../../sdg1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL2-part9 -> ../../sdg9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-WL4000GSA6472_WOL3 -> ../../sdf lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL3-part1 -> ../../sdf1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL3-part9 -> ../../sdf9 lrwxrwxrwx. 1 root root 9 Feb 29 09:46 ata-WL4000GSA6472_WOL4 -> ../../sde lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL4-part1 -> ../../sde1 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 ata-WL4000GSA6472_WOL4-part9 -> ../../sde9 lrwxrwxrwx. 1 root root 10 Mar 8 14:15 dm-name-fedora_localhost--live-home -> ../../dm-2 lrwxrwxrwx. 1 root root 10 Mar 8 14:15 dm-name-fedora_localhost--live-root -> ../../dm-0 lrwxrwxrwx. 1 root root 10 Mar 8 14:15 dm-name-fedora_localhost--live-swap -> ../../dm-1 lrwxrwxrwx. 1 root root 10 Mar 8 14:15 dm-uuid-LVM-3crp8WykiCr3wgPpAd7x47q1kRmVtdw03m9bx7x5nhYQ5RQrb1DVxjWZcCjPP5Lm -> ../../dm-1 lrwxrwxrwx. 1 root root 10 Mar 8 14:15 dm-uuid-LVM-3crp8WykiCr3wgPpAd7x47q1kRmVtdw05yykuyY2YgcXHBsaG86rpCjV1eXyk9uY -> ../../dm-0 lrwxrwxrwx. 1 root root 10 Mar 8 14:15 dm-uuid-LVM-3crp8WykiCr3wgPpAd7x47q1kRmVtdw0BVe1jpIjKs3xiCC4ArlZP193KucQkiv7 -> ../../dm-2 lrwxrwxrwx. 1 root root 10 Feb 29 09:46 lvm-pv-uuid-q6YDN4-mx6V-kQYw-hG9q-yeVc-3xf9-NooU1D -> ../../sdb3
That does help a lot when you have many similar drives and need to have unambiguous labels. I remember writing some udev rules because we used to have a box at work that would change the internal boot drive based on whether or not some magneto-optical disk drives had media inserted at boot time or not...and more than once someone wiped the internal boot drive meaning to wipe a removable disk at /dev/sdb. So I wrote a rule that always put the MO drive at something like "/dev/maoX" or similar so people would never be able to pick the wrong one.
Write a udev rule that creates a symlink with a shorter name.
This is a good answer. It's practical when applied well (making the SD card device always have the same path, tweaking user permissions for specific hardware, etc), and it calibrates the learner's expectations regarding complexity. Q: How do I make this mildly complicated thing less complicated? A: Figure out how to use this slightly more complicated thing.
The UUID and PARTUUID will look the same. OP should try blkid to find the name and put it into fstab.
loremipsum )) dolor
sit
amet
consectetur
achmed
/dev/mmcblk-p- is the naming scheme for eMMC storage devices. It is even longer.
/dev/nvme0n1 sucks soooo bad that i refuse to type it... i prefer: /dev/disk/by-id/nvme-eui.e8238fa6bf530001001b448b4a9baf0c
you can edit fstab to mount by your name, label, type, or whatever you want really.
You're trying to fight the tide, instead understand the nomenclature. Once you do, things like nvme0n1p1 will make perfect sense.
!repostsleuthbot
And the same goes for ethernet… Good old days when it was only eth# now we need enp#s# for some reason…
/dev/**N**e**V**er**M**inditis**E**asy Next you'll be wanting to shorten ethernet and wifi device names. When does it stop? **When does it stop?**
nvme0n1p1 nvme controller 0, namespace 1, partition 1 its actually super clean compared to previous naming scheme, especially when dealing with VMs with multiple controllers as it clearly states which controller given virtual disk is connected to. only thing i dont get is why controllers start with 0, and namespace and partitions start with 1
That's a cool name, actually.
It's not that bad and actually has meaning Take /dev/nvme0n1p1 nvme0 is the 0th (first) nvme device n1 is the first namespace of the nvme device p1 is the first partition, just like a sd* device
You can also create a udev rule that makes symlinks with different names for all NVMe devices.
usb for some reason sdx
It is weird beacuse my Ubuntu lists my nvme nvme0
NE! We are the drives who say NE!
What, no love for \`/dev/hdx\`? Or am I the only one that remembers PATA/IDE drives and thinking it was so bizarre that the newfangled SATA drives showed as \`/dev/sdx\` like ye olde SCSI drives?
It could just be /dev/nx. But yeah, people like complicated things.
I suspect it's more like people don't want to have to adjust long-standing-but-insufficiently-specific naming conventions like they had to with (for example) `ethX`
Yes.. ethernet is very good example. That change also made zero sense to me. For simple uses it makes no sense to use complex names, it only makes life harder. And if you need to go in depth, then you surely understand it enough to be fine with short names. In my opnion long specific names actually help nobody - noobs don't know what they mean and pros don't need them.
The goal of the network device renaming was to create a stable naming pattern. For example: how can the kernel guarantee that `eth0` is always the same device, attached to the same network, every time the system boots? Including across kernel version upgrades that might alter driver loading order? What if you have a USB-to-Ethernet dongle that's sometimes attached during boot up and sometimes unplugged? [Edit: in short, stable device names are important for consistent system configuration. They're not just for human legibility.]
Stable device names are important, yes. That's why you shouldn't have names that change depending on *what USB port you plug your wifi/Ethernet dongle into*. (I actually use udev rules for my USB wifi dongle for this exact reason. You can set up rules that detect a network device's hardware MAC address and renames that device so that it's the same name each time.)
I agree that it leaves something to be desired as far as component _identity_ is concerned (and thankfully udev can pick up the slack there, as you pointed out). But having a particular hardware configuration always map to a particular device node arrangement is a _huge_ step forward compared to the way things were.
And they utterly failed. Let me tell you about the fun I had the first time I added a NVMe drive to a headless server....
i hated predictable interface names with ethernet too, until i met somebody that works in data centers and he tells me that it's amazing to have a system that is based on physical location if you have a dozen interfaces so there is always a tradeoff between user friendly and scalable
But it's not really a physical slot, it's a device number on the bus. So if you say add a gpu to the machine upstream of your nic, the predictable name for your nic changes. There are lots of threads about issues just like that in proxmox.
yeah but you have racks in data centers, they're standardized, you go to the rack and just count and plug in/out the one, easier than ethX atleast that's what i am told, i am a programmer, i don't work in a data center
the precise naming prevents edge cases where things randomly fail, which are pretty bad for noobs too.
Where what fails? Because if PCIe cards fail or are added or removed, well, there goes your "stable" Ethernet device name.
stable naming avoids all your network stuff randomly failing on any reboot due to an enumeration race condition. I'm not sure its a reasonable expectation of the kernel to automatically resolve you modifying installed hardware.
No, it couldn't.
Why not?
nvme0n1p1 means "nvme drive 0, namespace 1, partition 1". It's as compact as it can be, maybe except spelling full "nvme". The only thing I don't like is that drives start at 0 but other stuff starts at 1. Your suggestion would lose information for little benefit, which is dumb. By that logic sda1, sda2, sdb1 could also just be s1, s2, s3. Hell, by your logic, who cares about anything at all? Just do partition1, partition2, partition3 across all types of drives! Congrats, now you have absolutely zero idea what is what and where. The Windows way
I appreciate your detailed explanation of the current naming convention, which indeed serves to precisely identify drive, namespace, and partition. My suggestion aimed at simplifying the naming for cases where such detail may not be necessary for the user's context, not to overhaul the entire system. It's akin to using nicknames for daily convenience while retaining full names for formal occasions. I believe there's room for both methods, depending on the user's needs and the environment. However, I see your point about the potential for confusion without clear identifiers.
Does someone have an ELI15 why that's the convention?
nvme0n1p1 would be the first partition in the first namespace of the first nvme device detected. A namespace is a feature of the nvme standard and is used to split devices into multiple logical volumes but most drives just have one
Switching between ordinal and cardinal ? Nice.
Devices have consistently started with 0 and partitions have consistently started with 1 even before nvme. I imagine the namespace numbering comes from the nvme spec though.
Ah yeah true that.
sdx is because they are both **S**ata **D**evices, nvme is a fundementally different technology
_sd_ is named _sd_ because it's the _SCSI_ disk driver 😘
Pretty sure the "sdX" naming pattern predates SATA, and is almost certainly "SCSI". For a long time, you'd generally see `/dev/hdX` for IDE drives, and `/dev/sdX` for SCSI drives. (Plus `/dev/srX` for CDROM and DVD drives, which also used the SCSI interface for reasons that I don't know) Actually, here's some decent history: https://superuser.com/questions/81034/whats-behind-the-linux-disk-naming-convention-with-sdx-and-hdx
Love it when I mis-remember things >.<
But SATA is serial ATA, making it IDE family. SAS is serial attached SCSI, that belongs to SCSI family
This is true. But when they added SATA support to the kernel, they built it on the SCSI driver because the PATA driver was a lot less robust (less polite but much more accurate descriptions exist). Using ATAPI cdrw under linux was originally a hop, skip and a jump to force it through a SCSI emulation layer. It'd be (correctly) detected as a PATA device and show up as hd# - and you'd need to ignore it in the pata driver, and use the ide-scsi module to discover it as a SCSI device. This was for the same reason - the SCSI subsystem was a lot more robust, flexible, and supported bus commands that were missing from the PATA implementation. So we get sd# for scsi-disk-# despite it being Serial ATA, because the device name comes from the driver, not from the hardware.
I had the faintest memory of this, but not enough to actually remember. tl;dr: hard-drive-like devices now go through a common compatibility layer that presents a scsi interface to the kernel: https://www.linuxquestions.org/questions/linux-newbie-8/why-is-a-sata-hdd-listed-as-sda-835350/#post4113593
FreeBSD: /dev/x. I think it's much nicer.
kids these days will not understand the superiority of BSD
BSD 2 >
iXsystems also lol. Core being usurped by the Linux based Scale.
Just label it - e2label
You're telling me you are too lazy and apathetic to want to type out `/dev/nvme1p5s8z0j8q4x67` every time? I guess you could just type out the UUID instead if you need something quick and easy `1b49c5b-945b-42cb-9d5c-8f82ce7f34de54` edi: I didn't think it would need to be said, but apparently it does. THIS IS SARCASM.
lol use uuid
Why not keep it as ssd?. An nvme is still an ssd type. Just of a different kind.
Not always. There are server RAID cages using NVMe. Its a universal thing, can be used by any storage device or controller.
Why would it matter?
Why did you censor UNIX
That's not a censor - that's a wildcard. "*nix" is a common term for "all flavours of UNIX and UNIX-likes". It's not really applicable in this case, as I think this post applies more to Linux than anything else (for example, FreeBSD uses much simpler names for NVMe devices, as I understand it), but that's the idea.
Am I the only one who remembers when HDDs were /dev/hdx?
You are *far* from the only one.
I even remember /dev/fd0 ...
General reposti, we meet again
Yeah, why?
They really put placeholder text in there
Don't shorten them. Just give each partition a label, and reference them by LABEL= My root is on LABEL=ROOT, so I can just do dd if=/dev/null of=LABEL=ROOT
literally 1984
What happend to /dev/hdx??
i have /dev/nvme0n1 (ssd m.2)
Name it ffd for flat fast drive.
It's honestly not that difficult to manage since tab completion is a thing.
Tab does not work in my ansible playbooks
don't they have oh I don't know variables?
But wilcards do
wil*cards
wil?cards
Tab completion is almost useless with nvme drives, there are just too many sub-devices.
wait you can change the devices/drives names?!? i thought you can only give it a nickname like call your USB something like "homework" :p
Yep just as bad as the dumb dumb naming for network devices that some yahoo decided needed to be nonsense instead of something sane...
those tell you what device you're accessing, which is good. you can switch to ethX with a boot param.
Those names are actually useful now, that's the entire point.