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.)
Quoted 7 lines · Jun Lion
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
Quoted 1 line · Liu Bo
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.