Messages in this thread | | | Date | Sat, 12 Aug 2000 19:43:32 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: NTFS-like streams? |
| |
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/
| |