Re: [qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?
Thank you for your clarification. Also, many thanks for maintaining the file-reflink storage driver. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/978266fe-07db-32a1-ba3f-23552919b298%40cock.li.
Re: [qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?
-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/hsG0ERp149HqvKt8FAmQDUo5fFIAALgAo 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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZANSjtEd6cUEfaZX%40mutt.
Re: [qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?
-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/hsG0ERp149HqvKt8FAmQDQg9fFIAALgAo 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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZANByPUMlA4PLqW4%40mutt.
[qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/db2302d3-8a9b-3dd8-4b3f-96ba31e065c4%40cock.li.