* State of nocow file attribute
@ 2012-08-15 10:12 Lluís Batlle i Rossell
[not found] ` <COL113-W11E89280DE29846698B431B0B60@phx.gbl>
2012-08-17 1:45 ` Liu Bo
0 siblings, 2 replies; 7+ messages in thread
From: Lluís Batlle i Rossell @ 2012-08-15 10:12 UTC (permalink / raw)
To: Btrfs mailing list
Hello,
some time ago we discussed on #btrfs that the nocow attribute for files wasn't
working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even
with the attribute set.
Chris mentioned to find a fix quickly for that, and posted some lines of change
into irc. But recently someone mentioned that 3.6-rc looks like still not
respecting nocow for files.
Is there really a fix upstream for that? Do nocow attribute on files work for
anyone already?
Regards,
Lluís.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: State of nocow file attribute
[not found] ` <COL113-W11E89280DE29846698B431B0B60@phx.gbl>
@ 2012-08-15 17:19 ` Lluís Batlle i Rossell
0 siblings, 0 replies; 7+ messages in thread
From: Lluís Batlle i Rossell @ 2012-08-15 17:19 UTC (permalink / raw)
To: Kyle Gates; +Cc: linux-btrfs
On Wed, Aug 15, 2012 at 08:05:11AM -0500, Kyle Gates wrote:
> > Is there really a fix upstream for that? Do nocow attribute on files work for
> > anyone already?
>
> IIRC the nocow attribute seems to work if the volume is mounted with "nodatasum"
Shouldn't nocow mean also nodatasum *only for that file*? I find it a bit
useless, to require whole fs nodatasum for per-file nocow to work.
Thank you,
Lluís.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: State of nocow file attribute
2012-08-15 10:12 State of nocow file attribute Lluís Batlle i Rossell
[not found] ` <COL113-W11E89280DE29846698B431B0B60@phx.gbl>
@ 2012-08-17 1:45 ` Liu Bo
2012-08-17 14:59 ` David Sterba
1 sibling, 1 reply; 7+ messages in thread
From: Liu Bo @ 2012-08-17 1:45 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: Btrfs mailing list, David Sterba
On 08/15/2012 06:12 PM, Lluís Batlle i Rossell wrote:
> Hello,
>
> some time ago we discussed on #btrfs that the nocow attribute for files wasn't
> working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even
> with the attribute set.
>
> Chris mentioned to find a fix quickly for that, and posted some lines of change
> into irc. But recently someone mentioned that 3.6-rc looks like still not
> respecting nocow for files.
>
> Is there really a fix upstream for that? Do nocow attribute on files work for
> anyone already?
>
Hi Lluís,
Dave had post a patch to fix it but only enabling NOCOW with zero sized file.
FYI, the patch is http://article.gmane.org/gmane.comp.file-systems.btrfs/17351
With the patch, you don't need to mount with nodatacow any more :)
And why it is only for only zero sized file:
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18046
thanks,
liubo
> Regards,
> Lluís.
> --
> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* (no subject)
2012-08-17 1:45 ` Liu Bo
@ 2012-08-17 14:59 ` David Sterba
2012-08-17 15:30 ` Liu Bo
0 siblings, 1 reply; 7+ messages in thread
From: David Sterba @ 2012-08-17 14:59 UTC (permalink / raw)
To: Liu Bo
Cc: Lluís Batlle i Rossell, Btrfs mailing list, David Sterba,
andrei.popa
On Fri, Aug 17, 2012 at 09:45:20AM +0800, Liu Bo wrote:
> On 08/15/2012 06:12 PM, Lluís Batlle i Rossell wrote:
> > some time ago we discussed on #btrfs that the nocow attribute for files wasn't
> > working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even
> > with the attribute set.
> >
> > Chris mentioned to find a fix quickly for that, and posted some lines of change
> > into irc. But recently someone mentioned that 3.6-rc looks like still not
> > respecting nocow for files.
> >
> > Is there really a fix upstream for that? Do nocow attribute on files work for
> > anyone already?
> >
>
> Dave had post a patch to fix it but only enabling NOCOW with zero sized file.
>
> FYI, the patch is http://article.gmane.org/gmane.comp.file-systems.btrfs/17351
>
> With the patch, you don't need to mount with nodatacow any more :)
>
> And why it is only for only zero sized file:
> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18046
the original patch http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18031
did two things, the reasoning why it is not allowed to set nodatasum in
general applies only to the second hunk but this
@@ -139,7 +139,7 @@ void btrfs_inherit_iflags(struct inode *inode, struct inode *dir)
}
if (flags & BTRFS_INODE_NODATACOW)
- BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW;
+ BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW | BTRFS_INODE_NODATASUM;
btrfs_update_iflags(inode);
}
---
is sufficient to create nocow files via a directory with NOCOW attribute
set, and all new files will inherit it (they are automatically
zero-sized so it's safe). This usecase is similar to setting the
COMPRESS attribute on a directory and all new files will inherit the
flag.
If Andrei wants to resend just this particular hunk, I'm giving it my ACK.
david
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re:
2012-08-17 14:59 ` David Sterba
@ 2012-08-17 15:30 ` Liu Bo
2012-08-21 14:33 ` State of nocow file attribute David Sterba
0 siblings, 1 reply; 7+ messages in thread
From: Liu Bo @ 2012-08-17 15:30 UTC (permalink / raw)
To: David Sterba; +Cc: Lluís Batlle i Rossell, Btrfs mailing list, andrei.popa
On 08/17/2012 10:59 PM, David Sterba wrote:
> On Fri, Aug 17, 2012 at 09:45:20AM +0800, Liu Bo wrote:
>> On 08/15/2012 06:12 PM, Lluís Batlle i Rossell wrote:
>>> some time ago we discussed on #btrfs that the nocow attribute for files wasn't
>>> working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even
>>> with the attribute set.
>>>
>>> Chris mentioned to find a fix quickly for that, and posted some lines of change
>>> into irc. But recently someone mentioned that 3.6-rc looks like still not
>>> respecting nocow for files.
>>>
>>> Is there really a fix upstream for that? Do nocow attribute on files work for
>>> anyone already?
>>>
>>
>> Dave had post a patch to fix it but only enabling NOCOW with zero sized file.
>>
>> FYI, the patch is http://article.gmane.org/gmane.comp.file-systems.btrfs/17351
>>
>> With the patch, you don't need to mount with nodatacow any more :)
>>
>> And why it is only for only zero sized file:
>> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18046
>
> the original patch http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18031
> did two things, the reasoning why it is not allowed to set nodatasum in
> general applies only to the second hunk but this
>
> @@ -139,7 +139,7 @@ void btrfs_inherit_iflags(struct inode *inode, struct inode *dir)
> }
>
> if (flags & BTRFS_INODE_NODATACOW)
> - BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW;
> + BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW | BTRFS_INODE_NODATASUM;
>
> btrfs_update_iflags(inode);
> }
> ---
>
> is sufficient to create nocow files via a directory with NOCOW attribute
> set, and all new files will inherit it (they are automatically
> zero-sized so it's safe). This usecase is similar to setting the
> COMPRESS attribute on a directory and all new files will inherit the
> flag.
>
> If Andrei wants to resend just this particular hunk, I'm giving it my ACK.
>
IMO the following is better, just make use of the original check. If you agree with this,
I'll send it as a patch :)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 6e8f416..d4e58df 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4721,8 +4721,10 @@ static struct inode *btrfs_new_inode(struct btrfs_trans_handle *trans,
if (btrfs_test_opt(root, NODATASUM))
BTRFS_I(inode)->flags |= BTRFS_INODE_NODATASUM;
if (btrfs_test_opt(root, NODATACOW) ||
- (BTRFS_I(dir)->flags & BTRFS_INODE_NODATACOW))
+ (BTRFS_I(dir)->flags & BTRFS_INODE_NODATACOW)) {
BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW;
+ BTRFS_I(inode)->flags |= BTRFS_INODE_NODATASUM;
+ }
}
insert_inode_hash(inode);
>
> david
> --
> 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
>
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: State of nocow file attribute
2012-08-17 15:30 ` Liu Bo
@ 2012-08-21 14:33 ` David Sterba
2012-08-21 15:04 ` Liu Bo
0 siblings, 1 reply; 7+ messages in thread
From: David Sterba @ 2012-08-21 14:33 UTC (permalink / raw)
To: Liu Bo
Cc: David Sterba, Lluís Batlle i Rossell, Btrfs mailing list,
andrei.popa
On Fri, Aug 17, 2012 at 11:30:14PM +0800, Liu Bo wrote:
> IMO the following is better, just make use of the original check. If you agree with this,
> I'll send it as a patch :)
I think it's cleaner to keep all flags that get inherited from the
directory -> new file at one place, ie btrfs_inherit_iflags(), than
having them scattered over the code.
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 6e8f416..d4e58df 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -4721,8 +4721,10 @@ static struct inode *btrfs_new_inode(struct btrfs_trans_handle *trans,
> if (btrfs_test_opt(root, NODATASUM))
> BTRFS_I(inode)->flags |= BTRFS_INODE_NODATASUM;
> if (btrfs_test_opt(root, NODATACOW) ||
> - (BTRFS_I(dir)->flags & BTRFS_INODE_NODATACOW))
> + (BTRFS_I(dir)->flags & BTRFS_INODE_NODATACOW)) {
> BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW;
> + BTRFS_I(inode)->flags |= BTRFS_INODE_NODATASUM;
> + }
> }
And even better, this particular check of dir->flags should be removed
entirely, because it duplicates the equivalent in
btrfs_inherit_iflags().
>
> insert_inode_hash(inode);
david
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: State of nocow file attribute
2012-08-21 14:33 ` State of nocow file attribute David Sterba
@ 2012-08-21 15:04 ` Liu Bo
0 siblings, 0 replies; 7+ messages in thread
From: Liu Bo @ 2012-08-21 15:04 UTC (permalink / raw)
To: David Sterba, Lluís Batlle i Rossell, Btrfs mailing list,
andrei.popa
On 08/21/2012 10:33 PM, David Sterba wrote:
> On Fri, Aug 17, 2012 at 11:30:14PM +0800, Liu Bo wrote:
>> IMO the following is better, just make use of the original check. If you agree with this,
>> I'll send it as a patch :)
>
> I think it's cleaner to keep all flags that get inherited from the
> directory -> new file at one place, ie btrfs_inherit_iflags(), than
> having them scattered over the code.
>
>>
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index 6e8f416..d4e58df 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -4721,8 +4721,10 @@ static struct inode *btrfs_new_inode(struct btrfs_trans_handle *trans,
>> if (btrfs_test_opt(root, NODATASUM))
>> BTRFS_I(inode)->flags |= BTRFS_INODE_NODATASUM;
>> if (btrfs_test_opt(root, NODATACOW) ||
>> - (BTRFS_I(dir)->flags & BTRFS_INODE_NODATACOW))
>> + (BTRFS_I(dir)->flags & BTRFS_INODE_NODATACOW)) {
>> BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW;
>> + BTRFS_I(inode)->flags |= BTRFS_INODE_NODATASUM;
>> + }
>> }
>
> And even better, this particular check of dir->flags should be removed
> entirely, because it duplicates the equivalent in
> btrfs_inherit_iflags().
>
Fine, it's cleaner now.
thanks,
liubo
>>
>> insert_inode_hash(inode);
>
>
> david
> --
> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-08-21 15:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-15 10:12 State of nocow file attribute Lluís Batlle i Rossell
[not found] ` <COL113-W11E89280DE29846698B431B0B60@phx.gbl>
2012-08-15 17:19 ` Lluís Batlle i Rossell
2012-08-17 1:45 ` Liu Bo
2012-08-17 14:59 ` David Sterba
2012-08-17 15:30 ` Liu Bo
2012-08-21 14:33 ` State of nocow file attribute David Sterba
2012-08-21 15:04 ` Liu Bo
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.