All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miao Xie <miaox@cn.fujitsu.com>
To: bo.li.liu@oracle.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 12:23:03 +0800	[thread overview]
Message-ID: <512AE727.2040800@cn.fujitsu.com> (raw)
In-Reply-To: <20130225034959.GA3480@liubo.jp.oracle.com>

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?

Thanks
Miao

> 
> thanks,
> liubo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2013-02-25  4:22 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 [this message]
2013-02-25  5:03             ` Liu Bo
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=512AE727.2040800@cn.fujitsu.com \
    --to=miaox@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.