[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.020 / U:66.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site