lkml.org 
[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NTFS-like streams?


On Sat, 12 Aug 2000, Alexander Viro wrote:
>
> 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.

Well, _that_ is a separate issue. I have no idea what the NTFS filesystem
low-level layout is, and for all I know it may have its own trouble. But I
don't actuall ysee the "hardlink+complex file" thing as a very hard thing
to do necessarily: the hard link part implies that there is just one
"inode" (whatever NT calls them), and then the complex behaviour is just
described by that (rather complex) single inode.

> > (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.

Well, that proposal I obviously have no trouble with at all. I think it's
a swell idea. I don't think it's necessarily the only way of doing things,
but I certainly agree that it seems to be a clever trick that gets around
a lot of problems in the implementation.

> It takes _less_. Linus, the only (and I mean it) issue is that we will
> need to lift the 255-anon-mounts limit.

[ Thinking about it ]

I don't think you necessarily need to fix even that.

I'm not positive that you even need a new "struct super_block". You could
use the same superblock, and just move some more information into the
vfsmount. Which _is_ easy to allocate, and doesn't have any of the
anon-mount list issues that the superblock has.

Besides, you _do_ want to have some good way to reach the underlying
superblock anyway, even from such a "sub-mount". Just sharing the sb
directly would be one easy way.

(No, I haven't checked all the details. There may be overriding reasons
why you'd not want to re-use the same superblock. And there may be tons of
small details too).

> 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.

I think it at the very least has to be somewhat automatic to be nicely
usable. But an autofs-like thing might be sufficient.

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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans