lvm2 has a new flag: nvme

Message

szatox · Post by **szatox** » Thu Feb 12, 2026 10:33 pm

[ebuild     U ] sys-fs/lvm2-2.03.37 [2.03.22-r7] USE="lvm readline udev -nvme% -sanlock (-selinux) -static -static-libs (-systemd) -thin -valgrind" 
                                                                        ^^^^^^

Web search was basically useless, AI assist only says "it builds nvme plugin for lvm". Great, I kinda already thought that would be the case.
What does it actually do though, and when is it needed?

Post by **sam_** » Thu Feb 12, 2026 10:49 pm

I tweaked the USE description based on what I could gather now:

commit wrote: - <flag name="nvme">Build and install NVMe plugin</flag>
+ <flag name="nvme">
+ Build and install NVMe plugin for determining the World-Wide Identification
+ (WWID) of an NVME device via <pkg>sys-libs/libnvme</pkg>.
+ </flag>

Anon-E-moose · Post by **Anon-E-moose** » Thu Feb 12, 2026 11:05 pm

Wwid looks like a "unique serial number" for the nvme, I assume for differentiating different devices, ie which drive is having trouble, etc

szatox · Post by **szatox** » Thu Feb 12, 2026 11:14 pm

So... Is it necessary for using lvm on nvme?
Or is it just for some advanced features, or maybe naming scheme? Like by-path, by-id and by-label?

I mean, I doubt lvm actually cares about the type of disk it's used with, so I don't really expect not having it to cause any issues, but in this case I don't understand why is it even there.
The first and most important thing is: is it going to make my system unbootable, and if it shouldn't default to "on"

From the quick look at the ebuild it seems to be adding a new dependency that didn't exist in older versions.

Post by **sam_** » Thu Feb 12, 2026 11:17 pm

It's just what Anon-E-moose said, for identifying the device in output.

pingtoo · Post by **pingtoo** » Thu Feb 12, 2026 11:18 pm

In addition to sam_ respond, I found from AI (Gemini)

With libnvme you get LVM "hardware aware", which mean

Atomic Writes: It can detect the NAWUN (Normal Atomic Write Unit) via libnvme. This ensures LVM doesn't split a metadata update across a physical page boundary, which prevents data corruption during power loss.
Direct Pathing: It allows LVM to better handle NVMe-over-Fabrics (NVMe-oF), identifying remote disks as if they were local PCIe devices.

I then check how one can do NVMe-oF, it is suggested, there are two kind

standard Linux Kernel implementation
- The "Daemon" equivalent: The kernel thread created by the nvmet and nvmet-tcp (or nvmet-rdma) modules.
- How it works: Once you configure the target (usually via nvmetcli or writing to /sys/kernel/config/nvmet/), the kernel itself opens port 4420 and listens for incoming encapsulated NVMe commands.
high-performance userspace framework
- The "Daemon" equivalent: A literal userspace process called nvmf_tgt
- How it works: This daemon uses polled-mode drivers. It "owns" the CPU cores and the NVMe hardware entirely, never letting the CPU sleep. It constantly checks the network card and the SSD for new work.

So I guess it is target for some kind of NAS environment. Although there could be benefit on the local where the get "Atomic Writes".

Post by **sam_** » Thu Feb 12, 2026 11:37 pm

I don't think that's true. It is only used for the WWID functionality, I checked.

szatox · Post by **szatox** » Thu Feb 12, 2026 11:37 pm

Ok, so it looks like enabling this flag might allow LVM to avoid scanning disks in order to discover PVs by their contents.
Looks safe either way.

Thanks, all

pingtoo · Post by **pingtoo** » Fri Feb 13, 2026 12:48 am

sam_ wrote:I don't think that's true. It is only used for the WWID functionality, I checked.

Yes, confirm lvm2 does not do "Atomic Writes" itself. Gemini said it rely on libdm (which I start thinking this might be another lye)

after I saw your post and I drill down with Gemini, it admit it is "hallucinating"

It said it give me a "pseudocode" code to explain how it could have worked.
It them explain how the "Atomic Writes" work, it said it is depend on kernel's nvme driver to do the work.

Trying to drill down further, it got more and more "creative", showing me all kind of functions, where when I search they don't exist.

I give up, too much lies. It is hopeless.

b11n · Post by **b11n** » Fri Feb 13, 2026 12:52 am

pingtoo wrote:I give up, too much lies. It is hopeless. :lol:

Promise?

pingtoo · Post by **pingtoo** » Fri Feb 13, 2026 12:56 am

b11n wrote:
pingtoo wrote:I give up, too much lies. It is hopeless.
Promise?

Yes, not on this subject any more.

No I learn a lot from this research, it is fun and you get to know what is NVMe-oF, I don't even know such thing exist prior to my AI research.

b11n · Post by **b11n** » Fri Feb 13, 2026 2:54 am

pingtoo wrote:I learn a lot from this research, it is fun and you get to know what is NVMe-oF, I don't even know such thing exist prior to my AI research. :lol:

You're also turning slop into crystallised slop, which will eventually be crawled upon by search engines that aren't smart enough to realise it's an informational red-herring, and probably spat back out in search summaries with this forum thread given as a citation. I know you didn't create that monster, but you're feeding it.

pingtoo · Post by **pingtoo** » Fri Feb 13, 2026 12:25 pm

I am glad szatox brought out this topic, I don't know much NVMe before this.

I am glad sam_ point out my incorrected information post. it help me learn more.

I am unhappy AI made a fool out of me because its "hallucination".

I hope someone who follow search engine found this may find it informational because it point to a mistake and understand what LVM2 can or cannot do.

I am glad it got point out the information were slop, so anyone/anything would know it is wrong information.