From: Josef Bacik <jbacik@fusionio.com>
To: David Sterba <dsterba@suse.cz>
Cc: Liu Bo <bo.li.liu@oracle.com>, Josef Bacik <JBacik@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Marios Titas <redneb8888@gmail.com>
Subject: Re: [PATCH] Btrfs: do not change inode flags in rename
Date: Tue, 26 Feb 2013 09:25:05 -0500 [thread overview]
Message-ID: <20130226142505.GF19641@localhost.localdomain> (raw)
In-Reply-To: <20130226123300.GU27541@twin.jikos.cz>
On Tue, Feb 26, 2013 at 05:33:00AM -0700, David Sterba wrote:
> On Tue, Feb 26, 2013 at 08:11:17AM +0800, Liu Bo wrote:
> > On Mon, Feb 25, 2013 at 01:56:47PM -0500, Josef Bacik wrote:
> > > On Sun, Feb 24, 2013 at 09:04:42PM -0700, Liu Bo wrote:
> > > > Before we forced to change a file's NOCOW and COMPRESS flag due to
> > > > the parent directory's, but this ends up a bad idea, because it
> > > > confuses end users a lot about file's NOCOW status, eg. if someone
> > > > change a file to NOCOW via 'chattr' and then rename it in the current
> > > > directory which is without NOCOW attribute, the file will lose the
> > > > NOCOW flag silently.
> > > >
> > > > This diables 'change flags in rename', so from now on we'll only
> > > > inherit flags from the parent directory on creation stage while in
> > > > other places we can use 'chattr' to set NOCOW or COMPRESS flags.
> > > >
> > >
> > > I'm of the mind we definitely shouldn't drop flags we've set previously, but I
> > > think we should also inherit any flags we have set on the directory, so if we
> > > move a file into a NOCOW directory we should inherit the flag. I'm not married
> > > to the idea, but it seems to make the most sense to me. Thanks,
> > >
> > (Said in another thread)
> > I'm ok with either one, but...
> > from some reports on the list, end users are more likely to control, use chattr
> > files by themselves, inheriting flags via moving a file to a new directory is
> > indeed not very welcomed.
> >
> > So for practical use, I assume that it's fairly enough to inherit flags only on
> > creation?
>
> I still haven't figured out in what cases the silent flag inheritance
> (for a non-empty) file would help and the user would be happy that it
> works like this.
>
K, I'll take this as it is then and drop my previous patch. Thanks,
Josef
prev parent reply other threads:[~2013-02-26 14:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-25 4:04 [PATCH] Btrfs: do not change inode flags in rename Liu Bo
2013-02-25 10:50 ` David Sterba
2013-02-25 14:41 ` Liu Bo
2013-02-25 18:56 ` Josef Bacik
2013-02-26 0:11 ` Liu Bo
2013-02-26 12:33 ` David Sterba
2013-02-26 14:25 ` Josef Bacik [this message]
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=20130226142505.GF19641@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=bo.li.liu@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=redneb8888@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).