public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Duane Griffin <duaneg@dghda.com>
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Correct EXT3_TOPDIR_FL behaviour
Date: Tue, 03 Jun 2008 14:52:20 -0600	[thread overview]
Message-ID: <20080603205220.GG2961@webber.adilger.int> (raw)
In-Reply-To: <e9e943910806021727h111b0e57qeea0032d164e0ffb@mail.gmail.com>

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.


  reply	other threads:[~2008-06-03 20:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  0:27 Correct EXT3_TOPDIR_FL behaviour Duane Griffin
2008-06-03 20:52 ` Andreas Dilger [this message]
2008-06-03 21:31   ` Duane Griffin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080603205220.GG2961@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=duaneg@dghda.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox