On Sat, 12 Aug 2000, Linus Torvalds wrote:
> That said, we obviously _can_ handle it - it's very similar to the
> loop-mount issue, after all. In many ways you could think of any complex
> object as a "mount-point" for the complex behaviour, and that should
> take care of most issues. It certainly takes care of the multi-link issue.
Umm... /me scratches head. /me silently suspects that internally these
"hardlinks" are implemented in rather funny ways. /me wants to know how
the green fsck does CHKDSK react on them and what actually happens.
> The complex object just becomes a "mini-filesystem within a filesystem",
> in fact. Which is conceptually right: the actual behaviour of that
> embedded filesystem is not necessarily at all as complex as the behaviour
> of the "full" filesystem.
>
> (And if you think of complex objects this way all the issues with renaming
> outside the object just go away entirely, as it turns into the standard
> case of renaming on a different filesystem - which simply does not work).
*bingo*
That's what I was proposing.
> The same thing can be conceptually used to create that wet dream of user
> mounts: going "inside" tar-files by just mounting them as a
> mini-filesystem on top of the file that is the tar archive. The strongest
> argument against that is probably the fact that "tar" is not that great a
> filesystem format ;)
>
> However, the "filesystem within a filesystem" approach certainly would
> require more VFS layer tinkering to get right. It might be a very
> successful approach, though.
It takes _less_. Linus, the only (and I mean it) issue is that we will
need to lift the 255-anon-mounts limit. The only problem I have with
podfuk and friends is their attempt to make mounting automatic ("you've
looked funny at foo.tar, we mount it"). If application says "I want to
treat foo.tar as tarfs" (not necessary doing the actual mounting; autofs-like
scheme will work fine) - no problem. And yes, that's a hell of a powerful
thing. Potentially there is a file-becoming-directory thing (confused
userland), but that may be worth saying "fix your userland, then" - amount
of breakage is probably limited.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST