How do I safely terminate COW on pre-existing files?

How do I safely terminate COW on pre-existing files?

[George Mitchell]

I want to eliminate the COW feature on all of my OS files.  It is a nice 
feature for user files, but I don't see a clear benefit for the actual 
OS files.  And I suspect that COW induced fragmentation is causing or 
aggravating problems with my system including the boot open_ctree 
problem.  I had planned to recursively chattr these files to "nodatacow" 
status but then I ran into this cryptic warning on the chattr man page:

(Note: For btrfs, the 'C' flag should be set on new or empty files. If 
it is set on a file which already has data blocks, it is undefined when 
the blocks assigned to the file will be fully stable.  If the  'C'  
flag  is set on a directory, it will have no effect on the directory, 
but new files created in that directory will the No_COW attribute.)

So what exactly does that mean?  Does it mean that it is unsafe?  Or 
does it mean that it is simply unreliable?  If I run a btrfs balance 
first will that clear out the COW snapshots and enable me to perform the 
recursive chattrs?  What is the best way to approach this?

Thanks for any tips,  George

Re: How do I safely terminate COW on pre-existing files?

[David Sterba]

On Thu, Jun 06, 2013 at 07:51:28PM -0700, George Mitchell wrote:
> I want to eliminate the COW feature on all of my OS files.  It is a nice
> feature for user files, but I don't see a clear benefit for the actual OS
> files.  And I suspect that COW induced fragmentation is causing or
> aggravating problems with my system including the boot open_ctree problem.

Fragmentation does not cause open_ctree boot problems, it could affect
boot speed.

> I had planned to recursively chattr these files to "nodatacow" status but
> then I ran into this cryptic warning on the chattr man page:
> 
> (Note: For btrfs, the 'C' flag should be set on new or empty files. If it is
> set on a file which already has data blocks, it is undefined when the blocks
> assigned to the file will be fully stable.  If the  'C'  flag  is set on a
> directory, it will have no effect on the directory, but new files created in
> that directory will the No_COW attribute.)
> 
> So what exactly does that mean?  Does it mean that it is unsafe?  Or does it
> mean that it is simply unreliable?  If I run a btrfs balance first will that
> clear out the COW snapshots and enable me to perform the recursive chattrs?
> What is the best way to approach this?

The COW status cannot be changed once a file has data, implementation
reasons. The cryptic message should tell you that doing chattr on a
non-empty file has undefined result, which in practice means that it
does nothing. The file's cow-status is kept intact.

Setting nocow on a directory has clear semantics, it sets nocow on any
new (empty) file just fine.

If you want to switch files between cow<->nocow, set the cow-status in
advance and then do cp.


david

Re: How do I safely terminate COW on pre-existing files?

[George Mitchell]

Thanks, I would never have understood the phrase "it is undefined when 
the blocks assigned to the file will be fully stable" without your 
further explanation.  The man page could be far clearer in its choice of 
wording.  At this point I have also discovered that setting the "nocow" 
flag also disables checksums, which should also be noted on the same man 
page, and I am not sure I want to do that anyway, especially in a raid1 
configuration.

I currently have two major problems.  The first is the open_ctree boot 
issue which NEVER occurs when I do a FULL (every directory and file) 
offline defragmentation immediately before boot.  That process ALWAYS 
guarantees I will see a clean boot.  So the problem may not be 
fragmentation, but certainly the defrag process is doing something that 
prevents the open_ctree issue from manifesting.  So that is the approach 
I will use until this thing is solved.  The second issue is the systemd 
journal corruption issue.  I don't have that problem on a parallel 
non-btrfs system on the same hardware.  BUT ... I just this morning 
moved the journal logging to an ext4 partition and the same journal 
corruption is occurring which tells me that this problem is most likely 
not related to btrfs at all and has something to do with the unique 
configuration of the system instead.  So that leave only the boot 
problem and I will just continue to use the very effective band-aid on 
that one until it is finally fixed upstream.

Thanks so much for taking the time to respond to my question.  It is 
MUCH appreciated.  - George

On 06/07/2013 04:52 AM, David Sterba wrote:
> On Thu, Jun 06, 2013 at 07:51:28PM -0700, George Mitchell wrote:
>> I want to eliminate the COW feature on all of my OS files.  It is a nice
>> feature for user files, but I don't see a clear benefit for the actual OS
>> files.  And I suspect that COW induced fragmentation is causing or
>> aggravating problems with my system including the boot open_ctree problem.
> Fragmentation does not cause open_ctree boot problems, it could affect
> boot speed.
>
>> I had planned to recursively chattr these files to "nodatacow" status but
>> then I ran into this cryptic warning on the chattr man page:
>>
>> (Note: For btrfs, the 'C' flag should be set on new or empty files. If it is
>> set on a file which already has data blocks, it is undefined when the blocks
>> assigned to the file will be fully stable.  If the  'C'  flag  is set on a
>> directory, it will have no effect on the directory, but new files created in
>> that directory will the No_COW attribute.)
>>
>> So what exactly does that mean?  Does it mean that it is unsafe?  Or does it
>> mean that it is simply unreliable?  If I run a btrfs balance first will that
>> clear out the COW snapshots and enable me to perform the recursive chattrs?
>> What is the best way to approach this?
> The COW status cannot be changed once a file has data, implementation
> reasons. The cryptic message should tell you that doing chattr on a
> non-empty file has undefined result, which in practice means that it
> does nothing. The file's cow-status is kept intact.
>
> Setting nocow on a directory has clear semantics, it sets nocow on any
> new (empty) file just fine.
>
> If you want to switch files between cow<->nocow, set the cow-status in
> advance and then do cp.
>
>
> david
>
>