On Sun, Mar 30, 2025 at 12:39:38AM +0000, David Holland wrote: > On Thu, Mar 27, 2025 at 05:42:03AM +0700, Robert Elz wrote: > > | Because vnds are specifically configured for mounts; the only thing > > | they're useful for is mounting a fs image that lives in a regular > > | file. > > > > No they're not, they can be used for playing with newfs variants, > > fsdb, fsck, resize_ffs, ... Nothing requires they be mounted. > > Those will all run on regular files. The only thing that requires a > device for a fs image is mount.
They could, but they don't in practice. In my SFS work I needed to explicitly add the functionality of allowing all tools to also run on disc images; UDF also but then I added that there too :) IIRC FFS/MSDOS tools other than the makefs demand a device node or they will not run. > But that's a backwards argument anyway. The point is that a vnd is a > shim whose purpose is to work around a weakness in the system > interfaces. (Namely, that you can't mount a fs image in a regular > file.) It has no state, and no semantics of its own either; it's just > a plug. Its currently implemented as a block translation service mapping blocks on file blocks and thus can't handle holes in the disc image file. This might have been fixed but I ran into this a couple of times. > It is perfectly reasonable for mount to create a vnd automatically > when you ask it to mount an image that's a regular file, and dispose > of it equally automatically later. Second that, just make it a clonable. As for cgd etc, it would be nice if you could give it a logical device file name that creates the device at the specified place, be it in /dev/cgds/whatever or ~/backupi-disc or whatever, creating a device node in the user specified place and removing it on unconfiguring. With regards, Reinoud
