[PATCH] virtio-blk: emit udev event when device is resized

[PATCH] virtio-blk: emit udev event when device is resized

[Milos Vyletel]

When virtio-blk device is resized from host (using block_resize from QEMU) emit
KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
custom udev rules which would take whatever action if such event occurs. As a
proof of concept I've created simple udev rule that automatically resize
filesystem on virtio-blk device.

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"

Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
---
 drivers/block/virtio_blk.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 8ad21a2..5990382 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct work_struct *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);
@@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct work_struct *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);
 }
-- 
1.7.1

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Rusty Russell]

Milos Vyletel <milos.vyletel@sde.cz> writes:

> When virtio-blk device is resized from host (using block_resize from QEMU) emit
> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
> custom udev rules which would take whatever action if such event occurs. As a
> proof of concept I've created simple udev rule that automatically resize
> filesystem on virtio-blk device.
>
> 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"

This looks fine to me, but I like to check with Greg before adding udev
callouts.... Greg?

BTW, if this is good, it's good for stable IMHO.

Cheers,
Rusty.

> Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
> ---
>  drivers/block/virtio_blk.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 8ad21a2..5990382 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct work_struct *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);
> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct work_struct *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);
>  }
> -- 
> 1.7.1

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Greg KH]

On Fri, Feb 22, 2013 at 10:14:49AM +1030, Rusty Russell wrote:
> Milos Vyletel <milos.vyletel@sde.cz> writes:
> 
> > When virtio-blk device is resized from host (using block_resize from QEMU) emit
> > KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
> > custom udev rules which would take whatever action if such event occurs. As a
> > proof of concept I've created simple udev rule that automatically resize
> > filesystem on virtio-blk device.
> >
> > 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"
> 
> This looks fine to me, but I like to check with Greg before adding udev
> callouts.... Greg?

Hm, I thought we were frowning apon running binaries from udev rules
these days, especially ones that might have big consequences (like
resizing a disk image) like this.

Kay, am I right?

We already emit KOBJECT_CHANGE events when block devices change, from
within the block core code.  Why is the patch below needed instead of
using these events that are already generated?  How are virtio block
devices special?

> BTW, if this is good, it's good for stable IMHO.

What bug does it fix?

thanks,

greg k-h

> Cheers,
> Rusty.
> 
> > Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
> > ---
> >  drivers/block/virtio_blk.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > index 8ad21a2..5990382 100644
> > --- a/drivers/block/virtio_blk.c
> > +++ b/drivers/block/virtio_blk.c
> > @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct work_struct *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);
> > @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct work_struct *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);
> >  }
> > -- 
> > 1.7.1

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Kay Sievers]

On Mon, Feb 25, 2013 at 11:12 PM, Greg KH <greg@kroah.com> wrote:

> Hm, I thought we were frowning apon running binaries from udev rules
> these days, especially ones that might have big consequences (like
> resizing a disk image) like this.
>
> Kay, am I right?

We removed most of them from the default setups, yes. But there is
nothing wrong if people want to ship that in some package or as custom
rules.

It looks fine to me, we would just not add such things to the default
set of of rules these days.

> We already emit KOBJECT_CHANGE events when block devices change, from
> within the block core code.  Why is the patch below needed instead of
> using these events that are already generated?  How are virtio block
> devices special?

I think we only do that for dm and md and a couple of special cases
like loop and read-only settings.

Kay

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Greg KH]

On Mon, Feb 25, 2013 at 11:39:52PM +0100, Kay Sievers wrote:
> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH <greg@kroah.com> wrote:
> 
> > Hm, I thought we were frowning apon running binaries from udev rules
> > these days, especially ones that might have big consequences (like
> > resizing a disk image) like this.
> >
> > Kay, am I right?
> 
> We removed most of them from the default setups, yes. But there is
> nothing wrong if people want to ship that in some package or as custom
> rules.
> 
> It looks fine to me, we would just not add such things to the default
> set of of rules these days.
> 
> > We already emit KOBJECT_CHANGE events when block devices change, from
> > within the block core code.  Why is the patch below needed instead of
> > using these events that are already generated?  How are virtio block
> > devices special?
> 
> I think we only do that for dm and md and a couple of special cases
> like loop and read-only settings.

What about when we repartition a block device?  I've seen the events
happen then.

Anyway, if you are ok with this, no objection from my side then Rusty.

thanks,

greg k-h

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Kay Sievers]

On Mon, Feb 25, 2013 at 11:43 PM, Greg KH <greg@kroah.com> wrote:
> On Mon, Feb 25, 2013 at 11:39:52PM +0100, Kay Sievers wrote:
>> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH <greg@kroah.com> wrote:
>>
>> > Hm, I thought we were frowning apon running binaries from udev rules
>> > these days, especially ones that might have big consequences (like
>> > resizing a disk image) like this.
>> >
>> > Kay, am I right?
>>
>> We removed most of them from the default setups, yes. But there is
>> nothing wrong if people want to ship that in some package or as custom
>> rules.
>>
>> It looks fine to me, we would just not add such things to the default
>> set of of rules these days.
>>
>> > We already emit KOBJECT_CHANGE events when block devices change, from
>> > within the block core code.  Why is the patch below needed instead of
>> > using these events that are already generated?  How are virtio block
>> > devices special?
>>
>> I think we only do that for dm and md and a couple of special cases
>> like loop and read-only settings.
>
> What about when we repartition a block device?  I've seen the events
> happen then.

Right, from the common block code we send events for removable media
changes like cdroms, sd cards, when a device is switched to read-only,
and when we re-scan a partition table like on re-partitioning. Most of
the other events are block subsystem-specific like this one. For
things like device-mapper they are used pretty heavily.

> Anyway, if you are ok with this, no objection from my side then Rusty.

Looks fine to me, it should not do any harm if there are not heavy
programs hooked up -- which is nothing the kernel could fix if people
do that. :)

Kay

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Milos Vyletel]

On Feb 25, 2013, at 5:39 PM, Kay Sievers <kay@vrfy.org> wrote:

> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH <greg@kroah.com> wrote:
> 
>> Hm, I thought we were frowning apon running binaries from udev rules
>> these days, especially ones that might have big consequences (like
>> resizing a disk image) like this.
>> 
>> Kay, am I right?
> 
> We removed most of them from the default setups, yes. But there is
> nothing wrong if people want to ship that in some package or as custom
> rules.
> 
> It looks fine to me, we would just not add such things to the default
> set of of rules these days.

That was not my intention. I just wanted to demonstrate that event like this
could be useful in cases like filesystem resize. We have a need for automatic
resize by our customers so we will ship our custom udev rules. It's perfectly
understandable that default udev rules will not have this.

Milos

> 
>> We already emit KOBJECT_CHANGE events when block devices change, from
>> within the block core code.  Why is the patch below needed instead of
>> using these events that are already generated?  How are virtio block
>> devices special?
> 
> I think we only do that for dm and md and a couple of special cases
> like loop and read-only settings.
> 
> Kay

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Milos Vyletel]

On Feb 25, 2013, at 5:12 PM, Greg KH <greg@kroah.com> wrote:

> On Fri, Feb 22, 2013 at 10:14:49AM +1030, Rusty Russell wrote:
>> Milos Vyletel <milos.vyletel@sde.cz> writes:
>> 
>>> When virtio-blk device is resized from host (using block_resize from QEMU) emit
>>> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
>>> custom udev rules which would take whatever action if such event occurs. As a
>>> proof of concept I've created simple udev rule that automatically resize
>>> filesystem on virtio-blk device.
>>> 
>>> 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"
>> 
>> This looks fine to me, but I like to check with Greg before adding udev
>> callouts.... Greg?
> 
> Hm, I thought we were frowning apon running binaries from udev rules
> these days, especially ones that might have big consequences (like
> resizing a disk image) like this.
> 
> Kay, am I right?
> 
> We already emit KOBJECT_CHANGE events when block devices change, from
> within the block core code.  Why is the patch below needed instead of
> using these events that are already generated?  How are virtio block
> devices special?
> 
>> BTW, if this is good, it's good for stable IMHO.
> 
> What bug does it fix?
> 

It is not really a bug but it definitely is useful enhancement to have in stable too. I
can imagine lots of people can benefit from this.

Milos

> thanks,
> 
> greg k-h
> 
>> Cheers,
>> Rusty.
>> 
>>> Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
>>> ---
>>> drivers/block/virtio_blk.c |    3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>>> index 8ad21a2..5990382 100644
>>> --- a/drivers/block/virtio_blk.c
>>> +++ b/drivers/block/virtio_blk.c
>>> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct work_struct *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);
>>> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct work_struct *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);
>>> }
>>> -- 
>>> 1.7.1

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Rusty Russell]

Milos Vyletel <milos.vyletel@sde.cz> writes:
> On Feb 25, 2013, at 5:12 PM, Greg KH <greg@kroah.com> wrote:
>
>> On Fri, Feb 22, 2013 at 10:14:49AM +1030, Rusty Russell wrote:
>>> Milos Vyletel <milos.vyletel@sde.cz> writes:
>>> 
>>>> When virtio-blk device is resized from host (using block_resize from QEMU) emit
>>>> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
>>>> custom udev rules which would take whatever action if such event occurs. As a
>>>> proof of concept I've created simple udev rule that automatically resize
>>>> filesystem on virtio-blk device.
>>>> 
>>>> 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"
>>> 
>>> This looks fine to me, but I like to check with Greg before adding udev
>>> callouts.... Greg?
>> 
>> Hm, I thought we were frowning apon running binaries from udev rules
>> these days, especially ones that might have big consequences (like
>> resizing a disk image) like this.
>> 
>> Kay, am I right?
>> 
>> We already emit KOBJECT_CHANGE events when block devices change, from
>> within the block core code.  Why is the patch below needed instead of
>> using these events that are already generated?  How are virtio block
>> devices special?
>> 
>>> BTW, if this is good, it's good for stable IMHO.
>> 
>> What bug does it fix?
>> 
>
> It is not really a bug but it definitely is useful enhancement to have in stable too. I
> can imagine lots of people can benefit from this.

But that applies to almost any enhancement :)

It will go in *next* merge window, not this one.

Thanks,
Rusty.

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Milos Vyletel]

----- Original Message -----
> Milos Vyletel <milos.vyletel@sde.cz> writes:
> > On Feb 25, 2013, at 5:12 PM, Greg KH <greg@kroah.com> wrote:
> >
> >> On Fri, Feb 22, 2013 at 10:14:49AM +1030, Rusty Russell wrote:
> >>> Milos Vyletel <milos.vyletel@sde.cz> writes:
> >>> 
> >>>> When virtio-blk device is resized from host (using block_resize from
> >>>> QEMU) emit
> >>>> KOBJ_CHANGE uevent to notify guest about such change. This allows user
> >>>> to have
> >>>> custom udev rules which would take whatever action if such event occurs.
> >>>> As a
> >>>> proof of concept I've created simple udev rule that automatically resize
> >>>> filesystem on virtio-blk device.
> >>>> 
> >>>> 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"
> >>> 
> >>> This looks fine to me, but I like to check with Greg before adding udev
> >>> callouts.... Greg?
> >> 
> >> Hm, I thought we were frowning apon running binaries from udev rules
> >> these days, especially ones that might have big consequences (like
> >> resizing a disk image) like this.
> >> 
> >> Kay, am I right?
> >> 
> >> We already emit KOBJECT_CHANGE events when block devices change, from
> >> within the block core code.  Why is the patch below needed instead of
> >> using these events that are already generated?  How are virtio block
> >> devices special?
> >> 
> >>> BTW, if this is good, it's good for stable IMHO.
> >> 
> >> What bug does it fix?
> >> 
> >
> > It is not really a bug but it definitely is useful enhancement to have in
> > stable too. I
> > can imagine lots of people can benefit from this.
> 
> But that applies to almost any enhancement :)
> 

Good point :) 

> It will go in *next* merge window, not this one.
> 

Cool, thanks.

Milos

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Asias He]

On 02/22/2013 03:02 AM, Milos Vyletel wrote:
> When virtio-blk device is resized from host (using block_resize from QEMU) emit
> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
> custom udev rules which would take whatever action if such event occurs. As a
> proof of concept I've created simple udev rule that automatically resize
> filesystem on virtio-blk device.
> 
> 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"
> 
> Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
> ---
>  drivers/block/virtio_blk.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 8ad21a2..5990382 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct work_struct *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 };

event is not used again. Why not just

char *envp[] = { "RESIZE=1", NULL };


>  	u64 capacity, size;
>  
>  	mutex_lock(&vblk->config_lock);
> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct work_struct *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);
>  }
> 

I tried the following with your automatically resize udev rules.

(qemu) block_resize vd0 500
Check the fs size in guest, it is 500Mb

(qemu) block_resize vd0 1200
Check the fs size in guest, it is still 500Mb

Can you try resizing multiple times? Does it work?

-- 
Asias

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Milos Vyletel]

----- Original Message -----
> On 02/22/2013 03:02 AM, Milos Vyletel wrote:
> > When virtio-blk device is resized from host (using block_resize from QEMU)
> > emit
> > KOBJ_CHANGE uevent to notify guest about such change. This allows user to
> > have
> > custom udev rules which would take whatever action if such event occurs. As
> > a
> > proof of concept I've created simple udev rule that automatically resize
> > filesystem on virtio-blk device.
> > 
> > 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"
> > 
> > Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
> > ---
> >  drivers/block/virtio_blk.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > index 8ad21a2..5990382 100644
> > --- a/drivers/block/virtio_blk.c
> > +++ b/drivers/block/virtio_blk.c
> > @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct
> > work_struct *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 };
> 
> event is not used again. Why not just
> 
> char *envp[] = { "RESIZE=1", NULL };
> 

You're right. This works too. I was looking at other modules in kernel
how they do it and this was commonly used. Take a look at block/genhd.c
media_change_notify_thread() function which does similar thing.

> 
> >  	u64 capacity, size;
> >  
> >  	mutex_lock(&vblk->config_lock);
> > @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct
> > work_struct *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);
> >  }
> > 
> 
> I tried the following with your automatically resize udev rules.
> 
> (qemu) block_resize vd0 500
> Check the fs size in guest, it is 500Mb
> 
> (qemu) block_resize vd0 1200
> Check the fs size in guest, it is still 500Mb
> 
> Can you try resizing multiple times? Does it work?

Yep, works for me. After each block_resize call I get udev event. I
was running udevadm monitor at that time. I've also tried running
udevd in debug mode and even if I try to bump size twice in a row
I get two separate udev events and resize2fs is triggered. 

[root@host ~]# lvresize -f -L +100M /dev/vgguests/evd2 && \
virsh blockresize resize vdb 1 && \
lvresize -f -L +100M /dev/vgguests/evd2 && \
virsh blockresize resize vdb 1
  Rounding size to boundary between physical extents: 128.00 MiB
  Extending logical volume evd2 to 31.38 GiB
  Logical volume evd2 successfully resized
Block device 'vdb' is resized
  Rounding size to boundary between physical extents: 128.00 MiB
  Extending logical volume evd2 to 31.50 GiB
  Logical volume evd2 successfully resized
Block device 'vdb' is resized

On guest I get this (from udevd --debug)
...
1361804003.724025 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' started
1361804003.725215 [4438] util_run_program: '/sbin/resize2fs' (stderr) 'resize2fs 1.41.12 (17-May-2010)'
1361804004.129329 [4437] event_queue_insert: seq 2073 queued, 'change' 'block'
1361804006.577235 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Filesystem at /dev/vdb is mounted on /mnt/backup; on-line resizing required'
1361804006.577251 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'old desc_blocks = 2, new_desc_blocks = 2'
1361804006.577254 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Performing an on-line resize of /dev/vdb to 8224768 (4k) blocks.'
1361804006.577257 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'The filesystem on /dev/vdb is now 8224768 blocks long.'
1361804006.577260 [4438] util_run_program: '/sbin/resize2fs' (stdout) ''
1361804006.577544 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' returned with exitcode 0
...
1361804006.702659 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' started
1361804006.703841 [4438] util_run_program: '/sbin/resize2fs' (stderr) 'resize2fs 1.41.12 (17-May-2010)'
1361804009.343332 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Filesystem at /dev/vdb is mounted on /mnt/backup; on-line resizing required'
1361804009.343351 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'old desc_blocks = 2, new_desc_blocks = 2'
1361804009.343356 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Performing an on-line resize of /dev/vdb to 8257536 (4k) blocks.'
1361804009.343362 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'The filesystem on /dev/vdb is now 8257536 blocks long.'
1361804009.343367 [4438] util_run_program: '/sbin/resize2fs' (stdout) ''
1361804009.343727 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' returned with exitcode 0
1361804009.343740 [4438] udev_watch_begin: adding watch on '/dev/vdb'

Milos

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Asias He]

On 02/25/2013 10:54 PM, Milos Vyletel wrote:
> ----- Original Message -----
>> On 02/22/2013 03:02 AM, Milos Vyletel wrote:
>>> When virtio-blk device is resized from host (using block_resize from QEMU)
>>> emit
>>> KOBJ_CHANGE uevent to notify guest about such change. This allows user to
>>> have
>>> custom udev rules which would take whatever action if such event occurs. As
>>> a
>>> proof of concept I've created simple udev rule that automatically resize
>>> filesystem on virtio-blk device.
>>>
>>> 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"
>>>
>>> Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
>>> ---
>>>  drivers/block/virtio_blk.c |    3 +++
>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>>> index 8ad21a2..5990382 100644
>>> --- a/drivers/block/virtio_blk.c
>>> +++ b/drivers/block/virtio_blk.c
>>> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct
>>> work_struct *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 };
>>
>> event is not used again. Why not just
>>
>> char *envp[] = { "RESIZE=1", NULL };
>>
> 
> You're right. This works too. I was looking at other modules in kernel
> how they do it and this was commonly used. Take a look at block/genhd.c
> media_change_notify_thread() function which does similar thing.

Well, which kernel version are you looking at.
media_change_notify_thread() is gone back in 2010. See commit: dddd9dc340.

>>
>>>  	u64 capacity, size;
>>>  
>>>  	mutex_lock(&vblk->config_lock);
>>> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct
>>> work_struct *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);
>>>  }
>>>
>>
>> I tried the following with your automatically resize udev rules.
>>
>> (qemu) block_resize vd0 500
>> Check the fs size in guest, it is 500Mb
>>
>> (qemu) block_resize vd0 1200
>> Check the fs size in guest, it is still 500Mb
>>
>> Can you try resizing multiple times? Does it work?
> 
> Yep, works for me. After each block_resize call I get udev event. I
> was running udevadm monitor at that time. I've also tried running
> udevd in debug mode and even if I try to bump size twice in a row
> I get two separate udev events and resize2fs is triggered. 

Turned on the debug info and looked into it again. It works for me now
and the udev event is seen.

Tested-by: Asias He <asias@redhat.com>

> [root@host ~]# lvresize -f -L +100M /dev/vgguests/evd2 && \
> virsh blockresize resize vdb 1 && \
> lvresize -f -L +100M /dev/vgguests/evd2 && \
> virsh blockresize resize vdb 1
>   Rounding size to boundary between physical extents: 128.00 MiB
>   Extending logical volume evd2 to 31.38 GiB
>   Logical volume evd2 successfully resized
> Block device 'vdb' is resized
>   Rounding size to boundary between physical extents: 128.00 MiB
>   Extending logical volume evd2 to 31.50 GiB
>   Logical volume evd2 successfully resized
> Block device 'vdb' is resized
> 
> On guest I get this (from udevd --debug)
> ...
> 1361804003.724025 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' started
> 1361804003.725215 [4438] util_run_program: '/sbin/resize2fs' (stderr) 'resize2fs 1.41.12 (17-May-2010)'
> 1361804004.129329 [4437] event_queue_insert: seq 2073 queued, 'change' 'block'
> 1361804006.577235 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Filesystem at /dev/vdb is mounted on /mnt/backup; on-line resizing required'
> 1361804006.577251 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'old desc_blocks = 2, new_desc_blocks = 2'
> 1361804006.577254 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Performing an on-line resize of /dev/vdb to 8224768 (4k) blocks.'
> 1361804006.577257 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'The filesystem on /dev/vdb is now 8224768 blocks long.'
> 1361804006.577260 [4438] util_run_program: '/sbin/resize2fs' (stdout) ''
> 1361804006.577544 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' returned with exitcode 0
> ...
> 1361804006.702659 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' started
> 1361804006.703841 [4438] util_run_program: '/sbin/resize2fs' (stderr) 'resize2fs 1.41.12 (17-May-2010)'
> 1361804009.343332 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Filesystem at /dev/vdb is mounted on /mnt/backup; on-line resizing required'
> 1361804009.343351 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'old desc_blocks = 2, new_desc_blocks = 2'
> 1361804009.343356 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'Performing an on-line resize of /dev/vdb to 8257536 (4k) blocks.'
> 1361804009.343362 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'The filesystem on /dev/vdb is now 8257536 blocks long.'
> 1361804009.343367 [4438] util_run_program: '/sbin/resize2fs' (stdout) ''
> 1361804009.343727 [4438] util_run_program: '/sbin/resize2fs /dev/vdb' returned with exitcode 0
> 1361804009.343740 [4438] udev_watch_begin: adding watch on '/dev/vdb'
> 
> Milos
> 


-- 
Asias

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Milos Vyletel]

----- Original Message -----
> On 02/25/2013 10:54 PM, Milos Vyletel wrote:
> > ----- Original Message -----
> >> On 02/22/2013 03:02 AM, Milos Vyletel wrote:
> >>> When virtio-blk device is resized from host (using block_resize from
> >>> QEMU)
> >>> emit
> >>> KOBJ_CHANGE uevent to notify guest about such change. This allows user to
> >>> have
> >>> custom udev rules which would take whatever action if such event occurs.
> >>> As
> >>> a
> >>> proof of concept I've created simple udev rule that automatically resize
> >>> filesystem on virtio-blk device.
> >>>
> >>> 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"
> >>>
> >>> Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
> >>> ---
> >>>  drivers/block/virtio_blk.c |    3 +++
> >>>  1 files changed, 3 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> >>> index 8ad21a2..5990382 100644
> >>> --- a/drivers/block/virtio_blk.c
> >>> +++ b/drivers/block/virtio_blk.c
> >>> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct
> >>> work_struct *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 };
> >>
> >> event is not used again. Why not just
> >>
> >> char *envp[] = { "RESIZE=1", NULL };
> >>
> > 
> > You're right. This works too. I was looking at other modules in kernel
> > how they do it and this was commonly used. Take a look at block/genhd.c
> > media_change_notify_thread() function which does similar thing.
> 
> Well, which kernel version are you looking at.
> media_change_notify_thread() is gone back in 2010. See commit: dddd9dc340.
>

Oh, you're right. I was looking at the rhel 6.3 kernel (2.6.32-279.19.1.el6)
before I switched to upstream branch and did the changes. Sorry about the
confusion.

Milos
 
> >>
> >>>  	u64 capacity, size;
> >>>  
> >>>  	mutex_lock(&vblk->config_lock);
> >>> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct
> >>> work_struct *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);
> >>>  }
> >>>
> >>
> >> I tried the following with your automatically resize udev rules.
> >>
> >> (qemu) block_resize vd0 500
> >> Check the fs size in guest, it is 500Mb
> >>
> >> (qemu) block_resize vd0 1200
> >> Check the fs size in guest, it is still 500Mb
> >>
> >> Can you try resizing multiple times? Does it work?
> > 
> > Yep, works for me. After each block_resize call I get udev event. I
> > was running udevadm monitor at that time. I've also tried running
> > udevd in debug mode and even if I try to bump size twice in a row
> > I get two separate udev events and resize2fs is triggered.
> 
> Turned on the debug info and looked into it again. It works for me now
> and the udev event is seen.
> 
> Tested-by: Asias He <asias@redhat.com>
> 
> > [root@host ~]# lvresize -f -L +100M /dev/vgguests/evd2 && \
> > virsh blockresize resize vdb 1 && \
> > lvresize -f -L +100M /dev/vgguests/evd2 && \
> > virsh blockresize resize vdb 1
> >   Rounding size to boundary between physical extents: 128.00 MiB
> >   Extending logical volume evd2 to 31.38 GiB
> >   Logical volume evd2 successfully resized
> > Block device 'vdb' is resized
> >   Rounding size to boundary between physical extents: 128.00 MiB
> >   Extending logical volume evd2 to 31.50 GiB
> >   Logical volume evd2 successfully resized
> > Block device 'vdb' is resized
> > 
> > On guest I get this (from udevd --debug)
> > ...
> > 1361804003.724025 [4438] util_run_program: '/sbin/resize2fs /dev/vdb'
> > started
> > 1361804003.725215 [4438] util_run_program: '/sbin/resize2fs' (stderr)
> > 'resize2fs 1.41.12 (17-May-2010)'
> > 1361804004.129329 [4437] event_queue_insert: seq 2073 queued, 'change'
> > 'block'
> > 1361804006.577235 [4438] util_run_program: '/sbin/resize2fs' (stdout)
> > 'Filesystem at /dev/vdb is mounted on /mnt/backup; on-line resizing
> > required'
> > 1361804006.577251 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'old
> > desc_blocks = 2, new_desc_blocks = 2'
> > 1361804006.577254 [4438] util_run_program: '/sbin/resize2fs' (stdout)
> > 'Performing an on-line resize of /dev/vdb to 8224768 (4k) blocks.'
> > 1361804006.577257 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'The
> > filesystem on /dev/vdb is now 8224768 blocks long.'
> > 1361804006.577260 [4438] util_run_program: '/sbin/resize2fs' (stdout) ''
> > 1361804006.577544 [4438] util_run_program: '/sbin/resize2fs /dev/vdb'
> > returned with exitcode 0
> > ...
> > 1361804006.702659 [4438] util_run_program: '/sbin/resize2fs /dev/vdb'
> > started
> > 1361804006.703841 [4438] util_run_program: '/sbin/resize2fs' (stderr)
> > 'resize2fs 1.41.12 (17-May-2010)'
> > 1361804009.343332 [4438] util_run_program: '/sbin/resize2fs' (stdout)
> > 'Filesystem at /dev/vdb is mounted on /mnt/backup; on-line resizing
> > required'
> > 1361804009.343351 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'old
> > desc_blocks = 2, new_desc_blocks = 2'
> > 1361804009.343356 [4438] util_run_program: '/sbin/resize2fs' (stdout)
> > 'Performing an on-line resize of /dev/vdb to 8257536 (4k) blocks.'
> > 1361804009.343362 [4438] util_run_program: '/sbin/resize2fs' (stdout) 'The
> > filesystem on /dev/vdb is now 8257536 blocks long.'
> > 1361804009.343367 [4438] util_run_program: '/sbin/resize2fs' (stdout) ''
> > 1361804009.343727 [4438] util_run_program: '/sbin/resize2fs /dev/vdb'
> > returned with exitcode 0
> > 1361804009.343740 [4438] udev_watch_begin: adding watch on '/dev/vdb'
> > 
> > Milos
> > 
> 
> 
> --
> Asias
> 

Re: [PATCH] virtio-blk: emit udev event when device is resized

[Rusty Russell]

Milos Vyletel <milos.vyletel@sde.cz> writes:

> When virtio-blk device is resized from host (using block_resize from QEMU) emit
> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
> custom udev rules which would take whatever action if such event occurs. As a
> proof of concept I've created simple udev rule that automatically resize
> filesystem on virtio-blk device.
>
> 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"
>
> Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>

OK, I collapsed the event[] line as suggested by Asias, and applied this.

Thanks,
Rusty.

From: Milos Vyletel <milos.vyletel@sde.cz>
Subject: virtio-blk: emit udev event when device is resized

When virtio-blk device is resized from host (using block_resize from QEMU) emit
KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
custom udev rules which would take whatever action if such event occurs. As a
proof of concept I've created simple udev rule that automatically resize
filesystem on virtio-blk device.

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"

Signed-off-by: Milos Vyletel <milos.vyletel@sde.cz>
Tested-by: Asias He <asias@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (minor simplification)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 8ad21a2..922bcb9 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -539,6 +539,7 @@ static void virtblk_config_changed_work(struct work_struct *work)
 	struct virtio_device *vdev = vblk->vdev;
 	struct request_queue *q = vblk->disk->queue;
 	char cap_str_2[10], cap_str_10[10];
+	char *envp[] = { "RESIZE=1", NULL };
 	u64 capacity, size;
 
 	mutex_lock(&vblk->config_lock);
@@ -568,6 +569,7 @@ static void virtblk_config_changed_work(struct work_struct *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);
 }