Re: [Xen-devel] [PATCH v2] Only call stat() when adding a disk if we expect a device to exist.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-04-26 at 13:17 +0100, Dave Scott wrote:

> 1. remove the cached stat results in disk_try_backend_args
> 2. in disk_try_backend(... PHY) we
>     * fail if not RAW or empty (as before)
>     * assume phy is ok if we have a hotplug script (as before)
>     * if we're in LIBXL_TOOLSTACK_DOMID, stat() the disk and call 
> libxl__try_backend
>     * if we're not in LIBXL_TOOLSTACK_DOMID then assume phy is ok 
> (basically we can't tell for sure)

Right, this is the case which concerned me. Roger probably has a better
handler than me but I think it is probably true to say that at least as
things stand phy was the only option in a driver domain. Maybe blktap1
(which libxl doesn't support) would have worked but blktap2 won't and
neither will qdisk.

I was looking at this as the most minimal fix:
@@ -236,9 +236,10 @@ int libxl__device_disk_set_backend(libxl__gc *gc, libxl_de
             return ERROR_INVAL;
         }
         memset(&a.stab, 0, sizeof(a.stab));
-    } else if (disk->backend == LIBXL_DISK_BACKEND_PHY &&
+    } else if ((disk->backend == LIBXL_DISK_BACKEND_PHY ||
+               disk->backend == LIBXL_DISK_BACKEND_UNKNOWN) &&
                disk->backend_domid == LIBXL_TOOLSTACK_DOMID &&
                !disk->script) {
         if (stat(disk->pdev_path, &a.stab)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Disk vdev=%s "
                              "failed to stat: %s",

but I'm not 100% sure of this. 

If it is right the arguable TAP should be included too, it's only qdisk
which can deal with things which aren't block or file (so the == PHY
should be a != QDISK).

Which begs the question whether your variant shouldn't also add a stat
in the tap case too?

> 2. in libxl__device_disk_set_backend we
>     * keep the CDROM sanity check
>     * don't do any stat()ing
>     * immediately call disk_try_backend (probing if UNKNOWN as before)
> 
> Does that make sense? I'll do a bit of testing now.

I think it might...

> 
> Cheers,
> Dave



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel