BTRFS – Disabling COW on a file or directory – NODATACOW
Recommend to set nodatacow – turn cow off – for the files that require fast IO and tend to get very big and get alot of random writes: such VMDK (vm disks) files and the like.
Copy on write: the tendancy to not overwrite old blocks, it will always try to write in new areas. Turning it off will overwrite old blocks.
Turn off COW on file or folder (only works on 0 byte sized files):
# chattr +C file
Turn on COW on file or folder (only works on 0 byte sized files):
# chattr -C file
Turn off COW on directory recursively:
# chattr -R +C file
Turn on COW on directory recursively:
# chattr -R -C file
See if COW is off, on file or folder with lsattr command output will have a big C for a file if its COW is disabled. If its COW is enabled there wont be a C, it would just be left as a dash -.
chattr +C only works on folders, and empty files. New files in folders that have +C will get the +C property (+C meaning nocow or COW is disabled)
# lsattr filename
filename See if COW is off, on directory:
# lsattr -d dirname
See attributes of everything down recursively: # lsattr -R | grep .
NOTE: you can still take snapshots even though COW is off (but how? magic but it works – snapshots just redo a pointer, lets just say a snapshot tells the FS to do COW for that moment, so the old blocks before then do not get overwritten even though COW was off for them), also you can mount a whole subvolume with and without COW with mount option nodatacow.
READ THIS UPDATE: http://www.infotinks.com/btrfs-nodatacow-reflink-copies-snapshots/
RULE OF THUMB: cow or nocow property on a folder doesn’t do anything to blocks on the filesystem. cow or nocow on a folder just determines if new files (or 0 byte sized files) in that folder will have cow or nocow. cow or nocow can only be applied to new files or 0 byte sized files. so you cant take cow away or give cow to a file that is already existing and if bigger than 0 bytes. (by cow I mean COW enabled, by nocow I mean COW disabled)
Thanks. Being new to Btrfs, I was wondering how my “nocow” files ended up in a snapshot. Your post cleared that up.
By the way, you might want to change “file” to “directory” in
Glad to be of service.
Your right when -R is used with chattr, “file” should technically be a directory (but it will still work on a regular file as well – didnt test but i reckon it will work – it will just not recurse into it, as it wont be able to). When chattr is used without -R it can get applied to a directory or to a file. Im just using file in the general linux term though, where it can be anything (file/directory/sym&hardlink/socket/device etc – but specifically file/directory)
Still, I’d like to find a way to disable cow on existing files. I’m using BitTorrent with btrfs drives, I guess there will be much fragmentation if cow is enabled when a file is being downloaded, no matter whether full or compact allocation is used. However, after downloads are finished, I’d like to cp –reflink=always to somewhere else to organise them. I’m not using mv because I’d like the torrent to keep seeding. And I guess fragmentation will be less an issue since there won’t be any writes.
I’m just curious, is there a way to enable cow cheaply?
You cant disable or enable the COW feature on a file for logical reasons, what the reason? it would have to rewrite it, so it would become a new file. Ideally one could write an app that removes all of the other fragments of the file and puts it together – but thats just the same as unfragmenting a file, or just reading in the file and writing it in order in a fresh new area. This already can happen with a simple copy. Instead of disable/enabling cow on an existing file, you can uncow a file, which does rewrite it. it seems messy but its not. it writes the file in another location from front to back (or back to front, the point is direction doesnt matter). then it deletes the original. it renames the new file to match the originals name. Here is a script that does that: http://ram.kossboss.com/uncow/. Ideally though if you dont have much freespace, and you have “holes” in your freespace, your uncowed file could be fragmented. So ideally you should have as much freespace in your system as your biggest file. So if your biggest files that your going to uncow are 2T and 2G, then you should have at least 2T. (even then you should hope all of that freespace is close together, you can more so guarantee freespace to be close together if your defrag and balance your system often). NOTE: latest kernel changes of btrfs might not require as much balancing.