Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?

[449f09c92]

I have /dev/xvdc configured as a 10GB swap and had to edit the relevant
code to disable CoW when volatile.img is created to avoid overloading
dom0 by checksum calculation when swapping out occurs in the VM.

Is there any reason why copy-on-write is enabled on volatile volumes
that are mostly used as swap? Just curious.

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

449f09c92:

> had to edit the relevant code to disable CoW when volatile.img is
> created

file-reflink doesn't inherently do CoW for volatile volumes, it just
defaults to whatever the underlying location on the filesystem does.
For Btrfs, to get nocow non-checksummed volatile volumes you could set
that up like:

# mkdir /var/lib/very-volatile
# chattr +C /var/lib/very-volatile
# qvm-pool add -o dir_path=/var/lib/very-volatile very-volatile file-reflink
# qubes-prefs default_pool_volatile very-volatile

Although it will only apply to *new* VMs created after that. To point
*existing* VMs' volatile volumes to the new pool, you'd currently have
to shut down qubesd and manually edit /var/lib/qubes/qubes.xml
(because the property is not exposed through 'qvm-volume config').

> Is there any reason why copy-on-write is enabled on volatile volumes
> that are mostly used as swap?

Disabling CoW and hence checksums (besides being specific to Btrfs -
file-reflink is filesystem agnostic) means losing protection against
on-disk bit rot. But storing data on the volatile volume doesn't mean
it is unimportant or even short-lived: It's not that unusual to have a
long-running VM with weeks of uptime. Corruption in its swapped memory
(or in diverged 'root' volume data, which too is stored on the
'volatile' volume) could be devastating.

Rusty
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmQDQg9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt86Og/+PufuJZNM8DcIfIOq1nMqqM8WP5NTF5j/7XyUGkMJYIQBk5O9rv01FNtK
ceOvWqGRPasHRU1WvCQmL5hrV2DndViNkjWJXW2AMxQgXUaR0lzR5yjTGwA3NmiL
orilLnW/zfgq+uBjdhsLSY/r8NAQQu2qYuPlzr3Ra0I96YGH9JG1N+5whXtI7vAF
IHvI6B1LgbQuS5CNp5E+5ewXmfSl3biw2QPaC/n07YDZbqFHUR701Oh+ZelqiYiZ
MAvSVlasTPo/8gJpLrjBtIw9hx2x/tzNuEE0bgXCQ3r0YAql084EO7JqV85QKikD
63X3U+2KrSiGHLppf2Q9IjS6JDT0Y7rdQUIdWeK3OFQX/8B/7eOe+lMUqMpDKAEo
8McMH/4jfdX6Kf/Z/tywOpVR2ioRi7xbgEejMfMIddNnEAPGvcXs5BTi+Azd4HR5
dvpQcFTrwS/VQ0pRbBVe0IfUDI1BwuTwD0xbij9zMBT+ZQ+S53Eu1y5XvAXlWrmd
PvueRhUK4Wef+Nrj+okDreDW4VZV927I4EDlceAK5srbrX4g62vDSidzmaj9u4O1
wCrHt3zgEyIbUsbWvu8dE31olTzt8gGX0bpZjVrHb4/ov75wVwBrRZSe2usMJw9N
XNlN6R5slFhJaq8OgKlUZQPEat6SlaoR04uqfP7CgrrzpLDpNL4=
=Suy+
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rusty Bird:

> Disabling CoW and hence checksums (besides being specific to Btrfs -
> file-reflink is filesystem agnostic)

Although for volatile volumes in particular it might be possible to
get away with (optionally, configured per-volume) attempting to set
the nocow flag and ignoring any failures. Not sure if even that is
worth implementing though, when it's already possible to configure a
dedicated nocow pool for those volumes.

The filesystem specificity I was thinking of is a bigger issue with
other (snap_on_start or save_on_stop) volume types. E.g. on Btrfs you
can only do a reflink ioctl if the source and destination files have
the same nocow status - a notion that is perfectly captured by making
the whole pool directory nocow or not, without any convoluted logic in
the file-reflink driver.

Rusty
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmQDUo5fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/1/RAAjTRYmolu9M59E72mNyEbuQa9eKbPQVK1GVmeqmTOxsFkFUSUMTGYwdtK
yWKDotQapfj/5DpRFVUF8//95ylmVb0il2UGL4dfx/oOEEnJmen/BN0mA7xcti9e
VNzf2VFjqjAiYQVtCO75/ICcc5RjWa1U3XLyjDmwSZVH+EinDxENQBGl6IV2he2x
A89K5skgYPgtHT+4ppUe0DLScBgzpD9Jhd4TwvRs7tb/yG+sMK3qk+H97KcD7Ohv
jnGubMnY1ypoZ700EICxZn9b9pZRDV0zlJZ7lbwbpKEQq8Sf29UhwDDySqiHJGkU
+cGhzd4Uq75o3OLTEtr+blh4gERj5W+AfoWQ3yXqkohSeMAAXtnYfXNvFc5NftDQ
jf0hV3Kqz1VlnxDarQ1YtWziEp8+fP2yfWJx5vDj+OZJ6lPAxX93ozR1uXJ2+1I1
wtRpTFmH+VDB/n2R8ArdnSaqa9FBCK4tfp0ljXOXc1u7Bt5wCDsItm/z4591L7IL
9ZClUPb144qZtCX8Bwv8tMmUHferFL4u+aVvPP7dfRKgtpAGeRWURIHRqs2VfmAC
+3PfK4vPMvk5WJg1djk9y74EG1ihTuAPpzu2NwcHnnx5J8Amm34iPEI9xzV4hrfE
QM8wdQLflFimUh3r4la1xIDdHHZ5GoWjuqb/FVaUGYSZw+eCWdU=
=7lz0
-----END PGP SIGNATURE-----

[449f09c92]

Thank you for your clarification.
Also, many thanks for maintaining the file-reflink storage driver.