Re: [qubes-devel] Re: Question about storage pool "file"
On 26/06/2019 09.50, Rusty Bird wrote: > > So this would not cause data loss. > > But there are bound to be some serious data loss bugs in 'file' - the > worst that I know of is that cloning or backing up a running VM will > likely result in corrupted data (in the destination), because those > operations read the live volume data while it is being modified: > > https://github.com/QubesOS/qubes-issues/issues/4324 Thanks for the comprehensive answer! My current backup solution takes a ZFS snapshot, mounts it read-only, then copies the data. VMs running during backups will have inconsistent file system volumes upon restore, but otherwise no biggie. Qubes ought to move to a model where the underlying system uses btrfs snapshots to do backups. That way we could rid ourselves of the existing complexity (at least for the private.img volumes). > > > my ZFS pool code > > Nice. Godspeed! > > I had been hoping that OpenZFS would finally get FICLONE support after > Or*cle ZFS got the Solaris equivalent a while ago - which would make > 'file-reflink' compatible with ZFS. But nothing really seems to be > happening on that front: > > https://github.com/zfsonlinux/zfs/issues/405 > > Rusty I hope that happens soon too. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e1df9ac7-0bba-39db-a707-72581b4d3e13%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: Question about storage pool "file"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Manuel Amador (Rudd-O): > > I haven't been able to understand the codebase for the "file" storage > > pool very well. That might be for the better... It's kind of the haunted house storage driver at this point. > > At which point in the lifetime of a VM do changes get merged down from > > the COW private.img to the base private img? Never: In 'file', private.img stores the complete *up-to-date* data (modified live if the VM is running) for the volume 'private', while private-cow.img stores only the differing *old* blocks that have been changed in private.img since volume start. commit() then just deletes private-cow.img (if revisions_to_keep==0) or renames it to private-cow.img.old (if revisions_to_keep==1). Whereas in 'file-reflink' it's the opposite: private.img stores the (complete) *old* data, and private-dirty.img stores the complete *up-to-date* data. > > If my machine crashes, what prevents the data in the COW private.img > > from being lost next time the VM starts? So this would not cause data loss. But there are bound to be some serious data loss bugs in 'file' - the worst that I know of is that cloning or backing up a running VM will likely result in corrupted data (in the destination), because those operations read the live volume data while it is being modified: https://github.com/QubesOS/qubes-issues/issues/4324 > my ZFS pool code Nice. Godspeed! I had been hoping that OpenZFS would finally get FICLONE support after Or*cle ZFS got the Solaris equivalent a while ago - which would make 'file-reflink' compatible with ZFS. But nothing really seems to be happening on that front: https://github.com/zfsonlinux/zfs/issues/405 Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl0TQAFfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt8RdBAAifHE2iNVl4rK5DpPM3KxEqsEjHJRq/Ug2OE964jstspIZhGf+HRNrM49 iW7VuRi0RIiY15h0dX3AjYWdJJum237fnSC7XWzNpspjI4xpAUZKDBYufBAxqV8o QvjLixpsI9LWNjBFOxld9ta50kkSrcWVt/0hbL1yGFaS5k+dXgfZsj1sjsb6WU9B EjXviKeMINk68ee9YyXPZH9O5IRcZHH8S2OLzk7OO+eHUh70emEDqzNgDEFwZU1m f1IA0REjcqPJK4r4rnkxtCWGYIcK3LH1iyeWk3/tOtoY0pZiytNux8q45owmStNS h/VFp7RfKTsCIFk3tnG80jsr8i8VdaaQBDw5o9OBIAFkWNT04tI8O3BrJEUWrHRh T9ffhdYce0szJtHx6X82onCoxMfkAadgdKxpYgu1Oq7C8wGKrfkarT0mCFuvaAoL 7UHbfcUF45ON/C8pbm4CEX8/EjFZbnAmyhVbYsPGUtDGKwEItltfn51SsFIDNnna 5DpZWtg8nIUPeVWy5wJ5NFZPstfsop1YC32PFXb5iPGJDC8EWZKMSdHygf2CG4KQ POljOjlP+2Jr3cA9e2R9EMOobrkY5hBoax4phMPB5aeb77NOLor226neXE6P/zqf 13g90v391TIXbMJLLCtwL2ivJQ/FwPo1/Q5HZd7edmrkxRpaZaw= =lXWr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190626095057.GA1693%40mutt. For more options, visit https://groups.google.com/d/optout.