Hi,
On 2024/06/07 11:26, Zdenek Kabelac wrote:
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'...
Fair. Or sync -f /path/to/mountpoint.
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 ??
Oh yea, that's very valid, so instead of just lvcreate the sysadmin
should sync -f /path/to/mountpoint *before* issuing lvcreate in the case
where "possibly X minutes from now" is acceptable. Guessing this can be
a --pre-sync argument for lvcreate but obviously the sysadmin is
perfectly capable (if he's aware of this caveat) just run sync -f
/path/to/mountpoint just before lvcreate.
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...
Was referring to the case where an LV is only active on *one* node at a
time, but it's on shared physical storage. Not even sure if a thin pool
can be active on more than one node at a time in such a case. This is
research I've not yet done. We tried gfs2 a few years back and the
sheer number of unresolvable failure scenarios at the time just had us
switch to glusterfs instead.
I think this can be considered closed now.
Thanks again for all the help and insight, I thoroughly enjoyed the
discussion too, it was most insightful and I learned a lot from it.
Kind regards,
Jaco
