Re: approach on getting nullfs to work again

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Wed, Feb 09, 2005 at 09:28:39PM -0800, Matthew Dillon wrote:
:>      Only for unionfs.  For nullfs (where no merging is taking place) I
:>      am pretty certain we don't have to fake file OR directory vnodes.
:
:Well, which mount point should fstat report? The nullfs [which is what
:I would expect] or the underlying filesystem [which would be more useful
:if you want to decide disk space usage etc.]? In the latter case, some
:programs might get confused by having the same device / inode pairs
:across different  mount points.
:
:Joerg

    It should report the nullfs mount of course.... and it can, easily.

    The fstat() device/inode pair issue could also be resolved if absolutely
    necessary but I don't think it is necessary.   People using nullfs are
    already dealing with a ton of special cases, I don't think having one
    or two more is going to create any issue that couldn't be easily solved.

    so, e.g. find -x would traverse through a nullfs mount if you were 
    mounting the nullfs on the same filesystem,  like nullfs mounting / onto
    /fubar.  But the practical solution to that is to mount it on some other
    filesystem like /tmp or /usr or even an MFS filesystem.

    One thing for sure, if that's the only problem we have it isn't worth
    the huge coding effort required to fake vnodes to 'fix' it.  It would
    just be a footnote in the manual page 'watch out for this situation'.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>