diff mbox

Online resize of virtio-blk device does not emit udev event

Message ID 1480007129.1209973.1361392485765.JavaMail.root@sde.cz
State New
Headers show

Commit Message

Milos Vyletel Feb. 20, 2013, 8:34 p.m. UTC 
Stefan,

that's essentially what I was trying to do. I wanted to get an opinion from
someone more familiar with the virtio-blk and kernel in general firs though.

It looks like none of the block drivers handle this. It may be good idea to
add some function to block/genhd.c where similar stuff already exists
(media_change_notify_thread() for example). 

In the meantime I've done some proof of concept work directly in virtio-blk
driver where I'm emitting uevent when disk is resized.

What I'm trying to do is basically automatically handle resizing of filesystem
on guest in case host resizes block device for guest. This kernel patch along
with simple udev rules takes care of it.


# cat /etc/udev/rules.d/98-virtio-resize.rules
ACTION=="change", KERNEL=="vd*", \
        ENV{RESIZE}=="1", \
        ENV{ID_FS_TYPE}=="ext[3-4]", \
        RUN+="/sbin/resize2fs /dev/%k"
ACTION=="change", KERNEL=="vd*", \
        ENV{RESIZE}=="1", \
        ENV{ID_FS_TYPE}=="LVM2_member", \
        RUN+="/sbin/pvresize /dev/%k"

Milos

----- Original Message -----
From: "Stefan Hajnoczi" <stefanha@gmail.com>
To: "Milos Vyletel" <milos.vyletel@sde.cz>
Cc: qemu-devel@nongnu.org
Sent: Wednesday, February 20, 2013 4:47:34 AM
Subject: Re: [Qemu-devel] Online resize of virtio-blk device does not emit udev event

On Tue, Feb 19, 2013 at 10:15:32PM +0100, Milos Vyletel wrote:
> I was looking at the virtblk_config_changed_work function in RHEL6.3 kernel's
> drivers/block/virtio_blk.c which I believe is the function handling blockresize
> and it does not look like it tries to emit any kobject uevent.
> 
> Before I jump into patching kernel my question is whether it makes sense to have
> such uevent? I surely can use a way how to detect capacity change from userspace.

I suggest checking how other block drivers (including the device-mapper
and scsi layers) handle resize.  Perhaps virtio_blk.c can follow an
existing approach.

Stefan

Comments

Stefan Hajnoczi Feb. 21, 2013, 8:54 a.m. UTC | #1 
On Wed, Feb 20, 2013 at 09:34:45PM +0100, Milos Vyletel wrote:
> It looks like none of the block drivers handle this.

drivers/md/dm*.c is a block driver and you showed that LVM
(device-mapper) does raise a uevent when the device is resized.  That
would be the place to look.

Stefan
Milos Vyletel Feb. 22, 2013, 5:32 p.m. UTC | #2 
----- Original Message -----
> On Wed, Feb 20, 2013 at 09:34:45PM +0100, Milos Vyletel wrote:
> > It looks like none of the block drivers handle this.
> 
> drivers/md/dm*.c is a block driver and you showed that LVM
> (device-mapper) does raise a uevent when the device is resized.  That
> would be the place to look.
> 

Thanks. That's where I was looking. Device mapper likes to use
uevents and they are all over place. However I found drivers/md/md.c
that uses uevents in same way as my proof of concept patch. I've
posted my patch to LKML to see what they think about it. In case
anyone is interested here's the link

https://patchwork.kernel.org/patch/2172791/

Milos
diff mbox

Patch

--- drivers/block/virtio_blk.c.orig 2013-02-20 11:14:54.000000000 -0500
+++ drivers/block/virtio_blk.c  2013-02-20 13:34:15.000000000 -0500
@@ -294,6 +294,8 @@  static void virtblk_config_changed_work(
    struct virtio_device *vdev = vblk->vdev;
    struct request_queue *q = vblk->disk->queue;
    char cap_str_2[10], cap_str_10[10];
+   char event[] = "RESIZE=1";
+   char *envp[] = { event, NULL };
    u64 capacity, size;

    mutex_lock(&vblk->config_lock);
@@ -323,6 +325,7 @@  static void virtblk_config_changed_work(

    set_capacity(vblk->disk, capacity);
    revalidate_disk(vblk->disk);
+   kobject_uevent_env(&disk_to_dev(vblk->disk)->kobj, KOBJ_CHANGE, envp);
 done:
    mutex_unlock(&vblk->config_lock);
 }