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