Fwd: Interaction of nodatacow and snapshots

Fwd: Interaction of nodatacow and snapshots

[Ross Boylan]

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).

I would appreciate cc's on the reply.

Thanks.
Ross Boylan

Re: Fwd: Interaction of nodatacow and snapshots

[Andrei Borzenkov]

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.