On 08/04/2016 06:43 AM, Cyrill Gorcunov wrote:
On Thu, Aug 04, 2016 at 04:34:57PM +0300, Pavel Emelyanov wrote:
+static int check_blkdev(struct fd_parms *p, int lfd)
+{
+ /*
+ * @ploop_major is module parameter actually,
+ * set to PLOOP_DEVICE_MAJOR by default. We may
+ * need to scan module params or access
+ * /sys/block/ploopX/dev to fetch major.
+ *
+ * For a while simply use predefined @major.
+ */
+ static const int ploop_major = 182;
Major numbers are typically macro-defined and sit in some header ;)
I don't want to spread Vz7 specific code into headers and such.
+ int maj = major(p->stat.st_rdev);
+
+ /*
+ * It's been found that systemd-udevd sometimes
+ * opens-up ploop device from inside of container,
+ * so allow him to do that.
+ */
+ if (maj == ploop_major)
+ return 0;
This worries me :( Ploop has some internal state, so if we catch a proggie
that configures that state, live migrate it and just re-open the ploop it
will __continue__ configuring that state and, since we've re-opened the
ploop from the beginning, this configuration will continue with an error...
Then we need to liftup this code and someone from ploop camp should help me
to gather ploop props which we could dump into image and restore then.
Assuming that we refuse to checkpoint ploop if its maintenance state !=
OFF, the following:
/sys/block/ploopX/pstate/*
/sys/block/ploopX/pdelta/*/*
may be enough. If it's not, let me know, and we'll think how to fix it.
Btw, please keep all the code interacting with ploop (ioctls,
/sys/block/ploopX/*) in libploop.
Thanks,
Maxim
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
