Dne 07. 06. 24 v 11:03 Jaco Kroon napsal(a):
Hi,
On 2024/06/07 00:17, Zdenek Kabelac wrote:
Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
Hi,
I'm guessing your "simple way" is workable for the generic case as well,
towards that end, is a relatively simple change to the lvm2 tools not perhaps
to add an syncfs() call to lvcreate *just prior* to freezing? The hard part is
probably to figure out if the LV is mounted somewhere, and if it is, to open()
that path in order to have a file-descriptor to pass to syncfs()? Obviously
if the LV isn't mounted none of this is a concern and we can just proceed.
Hi
There is no simple answer here -
a) 'sync' flushes all io for all disk in the system - user can play with tools
like hdparm -F /dev/xxxx - so still everything in range of 'admin's hand'...
b) it's about the definition of the 'snapshot' moment - do you want to take
snapshot as of 'now' or after possibly X minutes where everything has been
flushed and meanwhile new data flown-in ??
c) lvm2 needs some 'multi LV' atomic snapshot support...
d) with thin-pool and out-of-space potential it gets more tricky....
What would be more interesting is if cluster-lvm is in play and the origin LV
is active/open on an alternative node? But that's well beyond the scope of
our requirements (for now).
Clearly in the cluster case user can use multi-node active LV only in the case
there is something that is able to 'manage' this storage - i.g. gfs2. Surely
use of ext4/xfs this way is out of question...
Regards
Zdenek
