At Sun, 21 Jun 2009 16:47:28 -0400 (EDT), der Mouse
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: FreeBSD devfs support on NetBSD 5.0
>
> > Personally I think local permissions and ownership changes, symbolic
> > links, and the like need to be supported in a completely transparent
> > way, but that's almost trivial to do with a simplified type of
> > unified filesystem overlay mount, one which stores only meta-data
> > overrides for underlying files (or almost like an extension to the
> > umapfs, one which stores the new meta-data).
>
> I'm not so sure. You need new operations, peculiar to this mapping
> layer. It seems to me this mapping layer would need a way to represent
> "node FOO is like underlying node BAR (possibly with changes)", which
> is not that hard, except that you need a way to create such a thing
> when underlying node BAR has already been moved, in the same way, to
> BAR2.
Yes, rename is more difficult -- that's why I only mentioned (sym)links.
K.I.S.S. (at least for now) Don't dig yourself a hole that you're not
prepared to build a whole sub-basement into!
I.e. rename() always just fails on my ideal devfs.
I suppose it could be done with hard links and white-out files in the
upper layer just like in mount_union(), but I'm not sure it's
necessary.
> One of the biggest problems with devfs, it seems to me, is that it
> constrains where devices can exist. If you want a device node outside
> /dev, you have to mount a (heavily constrained) devfs there, which
> compels dedicating a directory to the device - you can't just plop a
> device down in a directory alongside other things. (I don't want this
> often, but when I do, there's usually not much else that will do.)
I've _never_ ever had to do such a thing, and I can't imagine why one
would ever do so, especially not on a system supporting symlinks.
Sure there's chroot() and it's ilk (which I don't normally use), but if
unlink() is also made to work for the meta-only-unionfs then just mount
another instance and unlink the stuff you don't want, then "upgrade" the
devfs and the overlay meta-only-unionfs mounts to read-only (the first
would prevent new device files from accidentally appearing).
> Disagree. The mapping layer has to keep its metadata _somewhere_. Or
> do you consider it acceptable to have to recreate it afresh each boot?
Yes, the meta-data only unionfs would obviously have to have backing
store. That could just be another slice of disk, or it could be a
vnd(4) attachment to a regular file, or it could be just like
mount_union(8) works now and just be another normal directory tree on
the root filesystem somewhere (which would just look like a bunch of
empty files and perhaps some symlinks) -- whatever works best.
There's a bit of a potential chicken&egg problem with doing this if the
admin is stupid enough to try to make things more complex than they need
to be, but otherwise I think it's quite straight forward.
> > You could still grab all this meta-data from the union FS by simply
> > collecting it with standard filesystem management tools, such as
> > "pax"
>
> I don't think so, not unless you either (a) extend pax to understand
> these nontraditional device special files or (b) use traditional
> major/minor device number pairs (in which case what have you actually
> gained?).
There's nothing non-traditional in what I've proposed. All tools would
see exactly the same kinds of files that one sees today in /dev. Devfs
should be indistinguishable from /dev today to the normal user.
You don't even need to teach your tools about filesystem layers if you
use the normal directory as backing-store form used now by
mount_union(8). (though we should probably teach some tools about
filesystem layers since we do have such things)
(hmmm... more tools might also do well to learn about white-out files,
though ls(1) and stat(1) and presumably dump/restore already know about
them -- maybe dump(8) is the best right way to backup the upper layer
anyway, and of course that comes for free if you use the normal
directory form of backing store just like mount_union(8) does today)
> > Other than that devfs should simply be a live representation as a
> > filesystem of the autoconf tree.
>
> Yes, that's the usual idea of devfs...and as far as I can see, you're
> handwaving all the hard problems by pushing them off into this magic
> mapping layer, without offering any idea how to solve them there.
We already have unionfs -- we just need to copy its code and delete all
that which deals with data blocks. It's just a SMOP to get a
meta-only-unionfs out of it. There's no magic necessary, and no hand-
waving either (though my Round Tuit probably isn't that big at the
moment). All the magic is already here!
Also keep in mind this meta-only-unionfs is just an additional feature
for those who do feel they need to have cross-boot persistent meta-data
for their /dev files. For everyone who's happy with the default
permissions and ownerships of the underlying devfs files at every boot
then that's all they need (assuming devfs can track runtime changes to
the permissions and ownerships of its objects such that they persist
until shutdown).
Hmmm... I wonder though -- maybe mount_union(8) would almost work right
now on a devfs for those who wanted cross-boot persistence for meta-data
changes. Maybe it already just does a mknod(2) when copying a
device-special file to the upper layer, and actually avoids doing a copy
except on link/rename/unlink (you don't want/need to copy a device file
to the upper layer just because you wrote to it!). That sounds too easy!
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpsEW3ktUIT5.pgp
Description: PGP signature