Btrfs devel - Jan 2013 - chattr +C vs. btrfs subvolume snapshot

What happens if you set an individual file inside a subvolume as nocow
(chattr +C) and then take a snapshot of that subvolume and modify the
file in both?

Will btrfs now ignore the nocow attribute completely or will it do "as
few copies as possible"? (I''d love to know if it''s
possible to visualize
the fragmentation of a single file.)
--
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

On Tue, Jan 08, 2013 at 12:37:11AM +0000, Jun Lion
wrote:
> What happens if you set an individual file inside a subvolume as nocow
> (chattr +C) and then take a snapshot of that subvolume and modify the
> file in both?
> 
> Will btrfs now ignore the nocow attribute completely or will it do "as
> few copies as possible"? (I''d love to know if it''s
possible to visualize
> the fragmentation of a single file.)
Well, btrfs nearly puts everything with a kind of "timestamp",
generation, which stands for transaction id.

For your case, the NOCOW file is created just before taking the
snapshot, so btrfs thinks of it being shared, and for shared parts, we
must COW it to keep everything right when trying to modify them.

And for the fragmentation, do you mean ''filefrag''?

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

On 2013-01-08 11:28 +0800, Liu Bo wrote:
> And for the fragmentation, do you mean ''filefrag''?
I was for something that would show how the data branches off across
different snapshots, --reflink copies etc.

filefrag looks interesting, thanks.
--
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