On 03-May-2000 Alexander Viro wrote:
> as tree scanning in autofs4 switches to new linkage/goes away[1] we are
>
> [1] I would really prefer the latter, but if it will be hard to do fast -
> fine, it will be switch to new linkage; I have that code.
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.
>> BTW, what happens if you umount a filesystem which has these scattered about
>> its namespace? Do they get cleaned up as part of the umount (appropriate
>> callback, etc), or do you need to clear them out before the umount? I
>> prefer
>> the former.
>
> 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.
>> Also, what happens if you attach one to a non-directory? Could you use it
>> to put arbiary "special files" into the namespace without having to do
>> anything special? It would make thinks like Pavel's podfuk more useful
>> without having to do horrible namespace hacks as he does now.
>
> Ummm... I'm not sure that I like the idea. Reason: I'm very suspicious of
> the situations when file turns into directory and back. I never seen it
> done right and in all cases when it had been done it was full of nasty
> special cases, kludges, etc. Mostly on the userland side of things, BTW.
> If you can do it in clean way and nothing will break I'll be only glad
> about that. Mechanism itself doesn't care for the type of that stuff, so I
> have no objections on that side. Just a nasty gut feeling...
Well, I don't see a good reason not to make a file respond to readdir. chdir
and chroot currently prevent any-nondirectory from being current, so you need
to have a more general notion of directory-ness to make them work on magic
files.
The other approach is to have a file act like a symlink under some
circumstances, but I haven't thought that through properly. That's essentially
what podfuk does at the moment, with its magic mapping to the /overlay tree.
Then there's the cases where all you want is some ordinary-looking files with
dynamic content. That doesn't involve overlaying any incompatible semantics;
it just means you have a file in the namespace which isn't on the filesystem (I
guess you could get the same effect with a filesystem which has a file as the
top-level dentry, but I seem to remember that didn't work very well last time I
tried it).
>> Also, when one is inserted between two real filesystems, it still needs to
>> be able to mediate namespace lookups. Autofs may need this to block access
>> to a filesystem while the daemon is umounting it.
>
> 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.
> <shrug> two times slower. At least something...
I suppose. It would be nice find some replacement for the fake block devices
for blockless filesystems.
J
