On 17.04.2021 20:27, Ross Boylan wrote: > Suppose some files or directories on a subvolume are set nodatacow. > And then one creates a snapshot of that subvolume. > And then does a send based on that snapshot. > > What happens? I've looked through the documentation and can not tell. > It doesn't sound > as if nodatacow is consistent with the whole snapshot mechanism, but I > don't see any > explicit statements that any of the above won't work. > > For example, I could imagine any of > 1. the snapshot or send command refuses to run. > 2. the snapshot completely omits anything that is nodatacow. That > would probably be tricky since the > directory with datacow above the object that is not datacow would > need to be altered to > omit the reference. > 3. the snapshot does an explicit copy (i.e., duplicates all the bits) > of all things nodatacow. > 4. the snapshot always shows the current (on the original subvolume) > version of the nodatacow files. > 5. results are unpredictable and unreliable. > 6. the snapshot removes the nodatacow attribute from everything on the > original subvolume. > 7. everything works fine (this one requires lots of imagination). >
nodatacow disables CoW for regular writes. Snapshots will unshare data on first write, so each subvolume has own copy which continues as nodatacow in each subvolume (subsequent writes will be in place). Unsharing happens for overwritten data only which can lead to fragmentation even for nodatacow files.
