tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sbin/umount
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
Home |
Main Index |
Thread Index |
Old Index