Linux Btrfs filesystem development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox