On Wed, 3 May 2000, Jeremy Fitzhardinge wrote:
> I'll happily get rid of the tree scanning if there's a better way of doing the
> same thing. I don't want to change the basic mechanism of autofs4 right at the
> moment though.
OK, then. In practical terms it means that right now autofs4 retains the
scanning but gets switched to vfsmount linkage, traps go after the
multiple-mount stuff and once they are in (if Linus approves such a
beast, that is) tree-scanning may go.
> > Hrrrmmm... Probably the former, but I can argue it both ways ;-)
>
> Well, you could get the latter behaviour from the former simply by holding an
> extra reference and preventing the umount, but you can't simulate the former
> from the latter.
Yep, but it means two damn mechanisms for removing them - you definitely
should be able to remove them explicitly and do it without umounting the
host.
[snip files-as-directories - let's get back to that stuff when somebody
will stand up and say "I'm going to start doing it right now", OK? Again,
mechanism doesn't care, so it won't take large changes of in that area.]
> > It depends. How much are you going to do with the filesystem before
> > umount(8)?
>
> Probably not a lot, but I was thinking of something a bit more general than
> autofs.
>
> Actually, it would be nice to see transitions just to get a sense of how much
> use a filesystem is getting.
I'ld rather see it done completely from userland. Theory: currently
umount(2) is expensive. Really expensive. The main reason being that we
are trying to shrink dcache way too early - before we know that tree is
not busy.
It can be helped. Notice that opened files will prevent the call
of shrink_dcache_sb() right now - you'll be stopped by ->mnt_count on
vfsmnt. Lookup-in-process will have the same effect. The only source of
situations when we can get to shrink_dcache_sb() and fail umount(2) looks
so: we do lookup, put vfsmount, do something and only after that put the
dentry. Which can be trivially fixed if we postpone mntput() until after
the dput(). Then may_umount() becomes utterly trivial - it should just
check ->mnt_count.
With light-weight umount(2) we are in completely different
situation - then the expiry code may be safely moved into userland.
> > <shrug> two times slower. At least something...
>
> I suppose. It would be nice find some replacement for the fake block devices
> for blockless filesystems.
Three words: stat(2). st_dev. POSIX.
