On Mon, Feb 25, 2013 at 12:23:03PM +0800, Miao Xie wrote:
> Onmon, 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:
> >>> Onfri, 22 Feb 2013 16:40:35 +0800, Liu Bo w
On Mon, Feb 25, 2013 at 12:23:03PM +0800, Miao Xie wrote:
> Onmon, 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:
> >>> Onfri, 22 Feb 2013 16:40:35 +0800, Liu Bo w
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 wrot
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
On Fri, Feb 22, 2013 at 04:19:27PM -0500, Marios Titas wrote:
> I think that many end users will find all this very confusing. They
> will never expect that renaming a file will cause it to suddenly lose
> one flag (NODATACOW) while preserving the other (NODATASUM).
> Especially since they cannot e
On Fri, Feb 22, 2013 at 05:34:47PM +0800, Miao Xie wrote:
> Onfri, 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
>
On Fri, Feb 22, 2013 at 5:00 AM, Liu Bo wrote:
> On Fri, Feb 22, 2013 at 04:10:37AM -0500, Marios Titas wrote:
>> You are right, your patch does improve the situation a bit. But it
>> still does not address the main issue. To illustrate that, consider
>> the following scenario:
>
> Sorry for so mu
On Fri, Feb 22, 2013 at 05:34:47PM +0800, Miao Xie wrote:
> Onfri, 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
>
On Fri, Feb 22, 2013 at 04:10:37AM -0500, Marios Titas wrote:
> You are right, your patch does improve the situation a bit. But it
> still does not address the main issue. To illustrate that, consider
> the following scenario:
Sorry for so much confusion for users.
Please let me explain the follo
Wouldn't though inheriting create all sorts of problems? For instance
check the example that I give in my other responese [1].
[1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg22396.html
On Fri, Feb 22, 2013 at 4:34 AM, Miao Xie wrote:
> On fri, 22 Feb 2013 16:40:35 +0800, Liu
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
You are right, your patch does improve the situation a bit. But it
still does not address the main issue. To illustrate that, consider
the following scenario:
touch test
chattr +C test
head -c 1048576 /dev/zero >> test
mv test test2
now test2 lost the C flag because it was renamed. But the data i
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 t
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.
On Fri, Feb 22, 2013 at 3:11 AM, Liu Bo wrote:
> A user reported some weird behaviours,
> if we move a file with the noCo
A user reported some weird behaviours,
if we move a file with the noCow flag to a directory without the
noCow flag, the file is now without the flag, but after remount,
we'll find the file's noCow flag comes back.
This is because we missed a proper inode update after inheriting
parent directory's
15 matches
Mail list logo