Correct EXT3_TOPDIR_FL behaviour - Kernel

This is a discussion on Correct EXT3_TOPDIR_FL behaviour - Kernel ; Hi folks, I'm looking at http://bugzilla.kernel.org/show_bug.cgi?id=9866 , where the reporter is claiming that EXT3_TOPDIR_FL (chattr +T) is behaving incorrectly by being inherited from the parent. As mentioned in the bug, it also only seems to only make sense for directories ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Correct EXT3_TOPDIR_FL behaviour

  1. Correct EXT3_TOPDIR_FL behaviour

    Hi folks,

    I'm looking at http://bugzilla.kernel.org/show_bug.cgi?id=9866, where
    the reporter is claiming that EXT3_TOPDIR_FL (chattr +T) is behaving
    incorrectly by being inherited from the parent. As mentioned in the
    bug, it also only seems to only make sense for directories but
    ext{2,3,4} is happy to set it on anything. It seems to me that the
    reporter is correct and the behaviour should be changed to prevent the
    flag being inherited and to limit it to directories only. If there is
    no disagreement I'll follow-up with patches accordingly.

    Cheers,
    Duane.

    --
    "I never could learn to drink that blood and call it wine" - Bob Dylan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Correct EXT3_TOPDIR_FL behaviour

    On Jun 03, 2008 01:27 +0100, Duane Griffin wrote:
    > I'm looking at http://bugzilla.kernel.org/show_bug.cgi?id=9866, where
    > the reporter is claiming that EXT3_TOPDIR_FL (chattr +T) is behaving
    > incorrectly by being inherited from the parent. As mentioned in the
    > bug, it also only seems to only make sense for directories but
    > ext{2,3,4} is happy to set it on anything. It seems to me that the
    > reporter is correct and the behaviour should be changed to prevent the
    > flag being inherited and to limit it to directories only. If there is
    > no disagreement I'll follow-up with patches accordingly.


    Yes, this is a problem that was mentioned previously, and hasn't been
    fixed yet. The TOPDIR_FL shouldn't be inherited, similar to the
    non-inheritance of INDEX_FL and EXTENTS_FL.

    It could be argued pretty easily that inheriting flags is usually wrong,
    and that we should instead specify which flags SHOULD be inherited,
    instead of repeatedly fixing bugs like this.

    Flags that I would propose should be inherited from directories to
    regular files and subdirectories are: SECRM, UNRM, SYNC, APPEND, NODUMP,
    NOATIME, COMPR, NOCOMPR, JOURNAL_DATA, NOTAIL, and DIRSYNC, EXTENTS.
    I'm not sure what the semantics of IMMUTABLE on a directory are, whether
    it is even possible to create a new file in such a directory, but by
    principle of least surprise it should probably be inherited.

    Flags that definitely do not make sense to be inherited are: DIRTY, ECOMPR,
    INDEX, IMAGIC, TOPDIR, HUGE_FILE.

    Flags that don't make sense to be set on non-file/dir inodes are: DIRTY,
    ECOMPR, INDEX, SECRM, UNRM, SYNC, APPEND, COMPR, NOCOMPR, JOURNAL_DATA,
    NOTAIL, DIRSYNC, TOPDIR, EXTENTS, HUGE_FILE (used for files > 2TB).

    Cheers, Andreas
    --
    Andreas Dilger
    Sr. Staff Engineer, Lustre Group
    Sun Microsystems of Canada, Inc.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Correct EXT3_TOPDIR_FL behaviour

    2008/6/3 Andreas Dilger :
    > On Jun 03, 2008 01:27 +0100, Duane Griffin wrote:
    >> I'm looking at http://bugzilla.kernel.org/show_bug.cgi?id=9866, where
    >> the reporter is claiming that EXT3_TOPDIR_FL (chattr +T) is behaving
    >> incorrectly by being inherited from the parent. As mentioned in the
    >> bug, it also only seems to only make sense for directories but
    >> ext{2,3,4} is happy to set it on anything. It seems to me that the
    >> reporter is correct and the behaviour should be changed to prevent the
    >> flag being inherited and to limit it to directories only. If there is
    >> no disagreement I'll follow-up with patches accordingly.

    >
    > Yes, this is a problem that was mentioned previously, and hasn't been
    > fixed yet. The TOPDIR_FL shouldn't be inherited, similar to the
    > non-inheritance of INDEX_FL and EXTENTS_FL.
    >
    > It could be argued pretty easily that inheriting flags is usually wrong,
    > and that we should instead specify which flags SHOULD be inherited,
    > instead of repeatedly fixing bugs like this.


    Right, I was wondering about the others.

    > Flags that I would propose should be inherited from directories to
    > regular files and subdirectories are: SECRM, UNRM, SYNC, APPEND, NODUMP,
    > NOATIME, COMPR, NOCOMPR, JOURNAL_DATA, NOTAIL, and DIRSYNC, EXTENTS.
    > I'm not sure what the semantics of IMMUTABLE on a directory are, whether
    > it is even possible to create a new file in such a directory, but by
    > principle of least surprise it should probably be inherited.
    >
    > Flags that definitely do not make sense to be inherited are: DIRTY, ECOMPR,
    > INDEX, IMAGIC, TOPDIR, HUGE_FILE.
    >
    > Flags that don't make sense to be set on non-file/dir inodes are: DIRTY,
    > ECOMPR, INDEX, SECRM, UNRM, SYNC, APPEND, COMPR, NOCOMPR, JOURNAL_DATA,
    > NOTAIL, DIRSYNC, TOPDIR, EXTENTS, HUGE_FILE (used for files > 2TB).


    OK, thanks. I'll fix these up at the same time then. At the moment,
    for ext3, it seems INDEX is being cleared on everything, IMMUTABLE and
    APPEND are being cleared on links, and DIRSYNC is cleared on
    non-directories.

    Cheers,
    Duane.

    --
    "I never could learn to drink that blood and call it wine" - Bob Dylan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread