On Fri, Nov 15, 2024 at 10:29:48AM -0600, Eric Blake wrote: > On Fri, Nov 15, 2024 at 09:43:29AM -0600, Eric Blake wrote: > > > > But if there are no such ioctls (and no desire to accept a patch to > > add them), then it looks like I _have_ to use /dev/nbd$N as the tag > > that I map back to server details, and just be extremely careful in my > > bookkeeping that I'm not racing in such a way that creates leaked > > devices or which closes unintended devices, regardless of whether > > there are secondary failures in trying to do the k8s bookkeeping to > > track the mappings. Ideas on how I can make this more robust would be > > appreciated (for example, maybe it is more reliable to use symlinks in > > the filesystem as my data store of mapped tags, than to try and > > directly rely on k8s CR updates to synchronize). > > I wonder if xattr might be what I want for associating a user-space > tag with the device. Nope, it looks like setxattr(2) used on /dev/nbd0 (as seen in a setfattr(1) strace) fails with EPERM when attempting to assign attributes to anything in /dev; ie. devtmpfs does not appear to support extended attributes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
