NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
snapshots and defrag - revisited...
I've seen several places in this forum where it's mentioned that defragmenting a share that has snapshots WILL cause the reference links between the primary files and the snapshot versions to be broken -- effectively forcing a copy on write.
There's also the following mention on the btrfs wiki:
- Caveat: since Linux 3.14-rc2, 3.13.4, 3.12.12 and 3.10.31 (which removed the snapshot-aware defragmentation) defragmenting a file which has a COW copy (either a snapshot copy or one made with cp --reflink or bcp) would produce two unrelated files. If you defragment a subvolume that had a snapshot, you would roughly double the disk usage, as the snapshot files would no longer be COW images of the originals.
So, imagine that you have a share with a single 500 GB file, and a single snapshot of that that share, but haven't modified the file. The snapshot will take no extra space (only 500 GB is consumed.) However, if you defrag the volume, the implication of the above statement is that the space consumed on the volume by this share (and it's snapshot) will double, as the snapshot copy and the original copy will no longer share the same data on the volume.
However, that's not what I'm seeing on my NAS...
As an example, I have a share on my NAS that's consuming 894 GB. There are 51 snapshots of that share available on the NAS. If the statement about defrag breaking reference links (and thereby forcing full data copies) was true all the time, a defrag would fail on my NAS that only has a grand total of 5.54 TB (5x 2TB in RAID6) as 45 TB of space would be needed to hold 51 unique/unrelated copies of the share. (Actually, slightly less than 45 TB, as the very first snapshots, when I was first copying the data to the share, would be smaller.) I ran a defrag on that volume, and nothing bad happened. My used space didn't go up, and my free space didn't go down.
So, either the NAS refused to defrag that volume, or defraging doesn't always break the COW (reference) links.
Can someone help me understand this? Is the NAS not defrag'ing any volume that I have snapshots for, or has the issue of COW links being broken on defrag been resolved?
3 Replies
Replies have been turned off for this discussion
I did some fairly extensive testing...
First, it appears that the breaking of reference links (snapshots) happens at a FILE level. Then, it will only happen IFF that particular file is fragmented when the defrag is run. So, the problem isn't nearly as bad as it's made out to be.
An example: assume you have a share with 200 files, each 1 MB in size. Of the 200 files, one of them is fragmented. Then you made a snapshot of the drive. (0 extra space used.) Then you run a defrag on the volume. During the defrag, the ONE file that was fragmented will be split from the snapshot, causing one extra megabyte of space to be used. That's it.
In that example, if none of the files were fragmented before the snapshot was made, then the defrag wouldn't have used any extra space.
If the files weren't fragmented, you made a snapshot, and then you modified one file (and caused it to fragment), the filesystem itself would use "copy on write" to make copies of the portions of the file that you modified, and modify only those portions. (So, the snapshot would reference the entire old file, and the non-snapshot would partially reference new data and partially reference the old file.) At this point, the non-snapshot file is fragmented, so when a defrag runs, it will "finish" splitting the file from the snapshot. It might be easier if you just assume that any modifications to a file that has snapshot copies will cause an entirely new file to be allocated on the disk (even if that's only partially true to begin with, it becomes fully true if you defrag.)
One other example is if you have those 200 files, and one of them is fragmented before you snapshot. Then you make 10 snapshots. So far, no extra space is being used. Then modify one file. Now if you defrag, then only one extra copy is made (and all 10 snapshots would share the still fragmented copy.) This assumes that netgear's s/w is not running the defrag on the snapshots. (It appears that netgear only is running the defrag on non-snapshot subvolumes. mdgm-ntgr, can you verify that?)
garyd9 wrote:
First, it appears that the breaking of reference links (snapshots) happens at a FILE level. Then, it will only happen IFF that particular file is fragmented when the defrag is run.
Correct. Though there are some use cases where files are essentially always fragmented when snapshots are frequently taken. An SQL database is one example. If the current database is in a snapshot, then any database update will fragment the file. That would also happen with a torrent.
taking this a bit further...
The frontview UI, for shares and LUNs has a configuration option called "Bit Rot Protection (Copy-on-write)" As far as I can tell, at the btrfs level, this controls the "C" attribute (as visible with lsattr and set with chattr.) btrfs documentation calls this a 'nocow' or 'nodatacow' attribute.
A normal person (or even one with a technical background) would probably assume that turning of copy on write would prevent copy on write from occurring. This would be useful for preventing duplicate copies being made on defrag.
Through no fault of Netgear, however, btrfs really mis-represents this attribute. It does NOT prevent copy on write. Oh, it will prevent you from doing "cp --reflink" from the shell, but that isn't something that most readyNAS users would be messing with anyway. It does NOT prevent snapshots and snapshots on nodatacow files, directories and subvolumes will STILL make use of COW regardless of this attribute. (I'm not sure if you can snapshot a subvolume mounted with the nodatacow mount option.)
What this attribute DOES block is the data checksum that helps with "bit rot" detection.
So... I have no idea what GOOD the attribute actually does. I suppose it might make disk writes a TINY bit faster (and perhaps btrfs scrubs a bit faster if all your shares have COW/bitrot protection turned off.)
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
