Le ven. 15 nov. 2024 à 14:00, lacsaP Patatetom <patate...@gmail.com> a écrit :
> Le ven. 15 nov. 2024 à 13:35, Frantisek Rysanek <frantisek.rysa...@post.cz> > a écrit : > >> > # qemu-nbd -c /dev/nbd0 file.qcow2 >> > # mount /dev/nbd0p1 /mnt -o uid=me >> > $ # do some changes in /mnt/... >> > >> Are you sure the changes have made it to the underlying file? >> If you do an umount here, a sync() is guaranteed. >> If you do not umount, at this point you may have some dirty >> writeback. >> So that the following QEMU instance may find the filesystem in a >> "factually out of date" state. I dare not say "inconsistent state", >> because this should theoretically be taken care of... maybe... >> >> > I manually flush the system caches to make sure my `file.qcow2` file is up > to date . > > > $ qemu-system-x86_64 -snapshot -hda file.qcow2 # with locking=off >> >> Read-only access is one thing. Maybe the QEMU instance will cope with >> that. >> >> Do you want the QEMU instance to *write* to the filesystem, by any >> chance? >> > > no, I don't need it. > `-snapshot` is there to prevent corruption of the assembly left in place. > > >> If you manage to force-mount the filesystem for writing, and you >> write some changes to it, how does your "outer host-side instance of >> the mounted FS" get to know? >> This is a recipe for filesystem breakage :-) >> >> You know, these are exactly the sort of problems, that get avoided by >> the locking :-) >> >> They also get avoided by "shared access filesystems" such as GFS2 or >> OCFS2, or network filesystems such as NFS or CIFS=SMBFS. Maybe CEPH >> is also remotely in this vein, although this is more of a distributed >> clustered FS, and an overkill for your scenario. >> >> Frank >> >> in any case, to avoid this kind of problem and make sure I have the right > data, I manually clear the system caches with `sudo bash -c “sync && sysctl > -q vm.drop_caches=3”` before calling qemu. > `-snapshot` is there to prevent corruption of the assembly left in place. > > regards, lacsaP. > after rereading the documentation (introduction @ https://qemu-project.gitlab.io/qemu/system/qemu-block-drivers.html#disk-image-file-locking), I've just had a look at “Linux OFD” to try to remove the lock on my `file.qcow2` file, but I haven't found anything there : if someone has a clue, I'm interested...
