| Submitter | Milos Vyletel |
|---|---|
| Date | Feb. 20, 2013, 8:34 p.m. |
| Message ID | <1480007129.1209973.1361392485765.JavaMail.root@sde.cz> |
| Download | mbox | patch |
| Permalink | /patch/222155/ |
| State | New |
| Headers | show |
Comments
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
----- 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
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); }
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