On Wednesday, 18 July 2018 15:37:24 CEST Richard W.M. Jones wrote: > The old vgscan API literally ran vgscan. When we switched to using > lvmetad (in commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this > stopped working because lvmetad now ignores plain vgscan commands > without the --cache option.
Yes and no, see below.
> +int
> +do_lvm_scan (int activate)
> {
> CLEANUP_FREE char *err = NULL;
> int r;
> + const char *argv[MAX_ARGS];
> + size_t i = 0;
>
> - r = command (NULL, &err,
> - "lvm", "vgscan", NULL);
> + ADD_ARG (argv, i, "lvm");
> + ADD_ARG (argv, i, "pvscan");
> + ADD_ARG (argv, i, "--cache");
--cache is basically the difference, and why it should work. This was
already touched in the past, see commit
2c4f154b91215e775c77920b291ac081e93542fd later amended by commit
19b0ae6c6502c4833c73e1b1bfa47b43a40f21e9. The second commit (i.e.
remove --cache) was done because older distros at that time had an old
lvm2 versions without lvmetad (or configured to not use lvmetad, even
if running). The recent commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8
changed the way lvmetad is run, although I do not remember if it is
safe to assume that lvmetad is both available and "usable" in all the
distros we support.
All in all, my suggestion would be the following:
1) since the behaviour of the vgscan API is changed, then revert
commit 19b0ae6c6502c4833c73e1b1bfa47b43a40f21e9, so its behaviour
will be as the patch does
2) add the new APIs in a second commit
This way the fix for vgscan could be backported to 1.38.x, if it is
safe enough, leaving the new API for 1.39+.
Also, just (1) should be enough to fix rhbz#1602353, since the decrypt
code already does vgscan + vg_activate_all, which is what lvm_scan
does.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
