On Sat, 12 Aug 2000, Christopher Vickery wrote:
> On Sat, 12 Aug 2000, Alexander Viro wrote:
>
> > That's more or less it. Oh, and have fun with link(2) if some filesystems
> > that have forks support it. If you've got a way to handle multiple links
> > to object that has children - I'll be glad to hear it.
>
> UWIN is Unix running on NT. On an NTFS partition, you can
> use cmd.exe to create named streams. Then you can use uwin
> to create hard links, which work in the "expected way":
Note that NT doesn't have quite the dentry cache that Linux has.
The Linux dentry cache is a very powerful entity, and is definitely one of
those "best thing since sliced bread" things - it allows us to do
absolutely wonderful stuff with very good performance, and at the same
time acts as a wonderful way of handling synchronization in a very natural
manner. However, it has some quite strict aliasing issues exactly because
of these synchronization issues, which makes the case Al mentions very
interesting indeed - more so than under NT or "traditional" UNIXes, say.
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.
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).
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.
Linus
-
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