Re: approach on getting nullfs to work again
: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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 11 之 15 篇)：