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.
