From: Liu Bo <bo.li.liu@oracle.com>
To: Miao Xie <miaox@cn.fujitsu.com>
Cc: dsterba@suse.cz, Marios Titas <redneb8888@gmail.com>,
btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: update inode flags when renaming
Date: Mon, 25 Feb 2013 13:03:58 +0800 [thread overview]
Message-ID: <20130225050357.GC3480@liubo.jp.oracle.com> (raw)
In-Reply-To: <512AE727.2040800@cn.fujitsu.com>
On Mon, Feb 25, 2013 at 12:23:03PM +0800, Miao Xie wrote:
> On mon, 25 Feb 2013 11:50:01 +0800, Liu Bo wrote:
> > On Fri, Feb 22, 2013 at 11:04:40PM +0100, David Sterba wrote:
> >> On Fri, Feb 22, 2013 at 05:34:47PM +0800, Miao Xie wrote:
> >>> On fri, 22 Feb 2013 16:40:35 +0800, Liu Bo wrote:
> >>>> On Fri, Feb 22, 2013 at 03:32:50AM -0500, Marios Titas wrote:
> >>>>> Sorry, but the bug persists even with the above patch.
> >>>>>
> >>>>> touch test
> >>>>> chattr +C test
> >>>>> lsattr test
> >>>>> mv test test2
> >>>>> lsattr test2
> >>>>>
> >>>>> In the above scenario test2 will not have the C flag.
> >>>>
> >>>> What do you expect? IMO it's right that test2 does not have the C flag.
> >>>
> >>> No, it's not right.
> >>> For the users, they expect the C flag is not lost because they just do
> >>> a rename operation. but fixup_inode_flags() re-sets the flags by the
> >>> parent directory's flag.
> >>>
> >>> I think we should inherit the flags from the parent just when we create
> >>> a new file/directory, in the other cases, just give a option to the users.
> >>> How do you think about?
> >>
> >> I agree with that. The COW status of a file should not be changed at all
> >> when renamed. The typical users are database files and vm images, losing
> >> the NOCOW flag just from moving here and back is quite unexpected.
> >>
> >> david
> >
> > Yeah, I agree to remove this bad 'change in rename', will send a patch to
> > address it.
>
> I think we can add a mount option, if the option is set, when we move a file
> to a new directory, or create a new file, we will inherit the flags of the parent.
> If not set, we inherit the flags only when create a new file.
> How do you think about it?
>
I'm ok with the option, 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?
thanks,
liubo
next prev parent reply other threads:[~2013-02-25 5:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 8:11 [PATCH] Btrfs: update inode flags when renaming Liu Bo
2013-02-22 8:32 ` Marios Titas
2013-02-22 8:40 ` Liu Bo
2013-02-22 9:10 ` Marios Titas
2013-02-22 10:00 ` Liu Bo
2013-02-22 21:19 ` Marios Titas
2013-02-22 22:21 ` David Sterba
2013-02-22 9:34 ` Miao Xie
2013-02-22 9:50 ` Marios Titas
2013-02-22 10:06 ` Liu Bo
2013-02-22 22:04 ` David Sterba
2013-02-25 3:50 ` Liu Bo
2013-02-25 4:23 ` Miao Xie
2013-02-25 5:03 ` Liu Bo [this message]
2013-02-25 11:22 ` David Sterba
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=20130225050357.GC3480@liubo.jp.oracle.com \
--to=bo.li.liu@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
--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