krbd & live resize

krbd & live resize

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

Hi,

This works:

lvcreate --name tmp --size 10G all
  Logical volume "tmp" created
mkfs.ext4 /dev/all/tmp
mount /dev/all/tmp /mnt
blockdev --getsize64 /dev/all/tmp
10737418240
lvextend -L+1G /dev/all/tmp
  Extending logical volume tmp to 11,00 GiB
  Logical volume tmp successfully resized
blockdev --getsize64 /dev/all/tmp
11811160064
resize2fs /dev/all/tmp 
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
The filesystem on /dev/all/tmp is now 2883584 blocks long.

This does not work:

rbd create --size 10240 tmp
rbd info tmp
rbd image 'tmp':
	size 10240 MB in 2560 objects
	order 22 (4096 KB objects)
	block_name_prefix: rb.0.12dd.238e1f29
	format: 1
rbd map tmp
mkfs.ext4 /dev/rbd1
mount /dev/rbd1 /mnt
blockdev --getsize64 /dev/rbd1
10737418240
rbd resize --size 20000 tmp
blockdev --getsize64 /dev/rbd1
10737418240
resize2fs /dev/rbd1 
resize2fs 1.42 (29-Nov-2011)
The filesystem is already 2621440 blocks long.  Nothing to do!

It does work after umounting:

umount /mnt
blockdev --getsize64 /dev/rbd1
fsck -f /dev/rbd1
resize2fs /dev/rbd1 
resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
The filesystem on /dev/rbd1 is now 5120000 blocks long.

I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: krbd & live resize

[Laurent Barbe]

Hello Loic,

which version of kernel do you use for krbd ?

Laurent


Le 29/07/2013 23:50, Loic Dachary a écrit :
> Hi,
>
> This works:
>
> lvcreate --name tmp --size 10G all
>    Logical volume "tmp" created
> mkfs.ext4 /dev/all/tmp
> mount /dev/all/tmp /mnt
> blockdev --getsize64 /dev/all/tmp
> 10737418240
> lvextend -L+1G /dev/all/tmp
>    Extending logical volume tmp to 11,00 GiB
>    Logical volume tmp successfully resized
> blockdev --getsize64 /dev/all/tmp
> 11811160064
> resize2fs /dev/all/tmp
> resize2fs 1.41.12 (17-May-2010)
> Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
> old desc_blocks = 1, new_desc_blocks = 1
> Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
> The filesystem on /dev/all/tmp is now 2883584 blocks long.
>
> This does not work:
>
> rbd create --size 10240 tmp
> rbd info tmp
> rbd image 'tmp':
> 	size 10240 MB in 2560 objects
> 	order 22 (4096 KB objects)
> 	block_name_prefix: rb.0.12dd.238e1f29
> 	format: 1
> rbd map tmp
> mkfs.ext4 /dev/rbd1
> mount /dev/rbd1 /mnt
> blockdev --getsize64 /dev/rbd1
> 10737418240
> rbd resize --size 20000 tmp
> blockdev --getsize64 /dev/rbd1
> 10737418240
> resize2fs /dev/rbd1
> resize2fs 1.42 (29-Nov-2011)
> The filesystem is already 2621440 blocks long.  Nothing to do!
>
> It does work after umounting:
>
> umount /mnt
> blockdev --getsize64 /dev/rbd1
> fsck -f /dev/rbd1
> resize2fs /dev/rbd1
> resize2fs 1.42 (29-Nov-2011)
> Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
> The filesystem on /dev/rbd1 is now 5120000 blocks long.
>
> I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?
>
> Cheers
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: krbd & live resize

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]



On 30/07/2013 11:55, Laurent Barbe wrote:
> Hello Loic,
> 
> which version of kernel do you use for krbd ?

Linux i-csnces-0000 3.2.0-41-generic #66-Ubuntu SMP

That may explain a few things ... :-)

> 
> Laurent
> 
> 
> Le 29/07/2013 23:50, Loic Dachary a écrit :
>> Hi,
>>
>> This works:
>>
>> lvcreate --name tmp --size 10G all
>>    Logical volume "tmp" created
>> mkfs.ext4 /dev/all/tmp
>> mount /dev/all/tmp /mnt
>> blockdev --getsize64 /dev/all/tmp
>> 10737418240
>> lvextend -L+1G /dev/all/tmp
>>    Extending logical volume tmp to 11,00 GiB
>>    Logical volume tmp successfully resized
>> blockdev --getsize64 /dev/all/tmp
>> 11811160064
>> resize2fs /dev/all/tmp
>> resize2fs 1.41.12 (17-May-2010)
>> Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
>> old desc_blocks = 1, new_desc_blocks = 1
>> Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
>> The filesystem on /dev/all/tmp is now 2883584 blocks long.
>>
>> This does not work:
>>
>> rbd create --size 10240 tmp
>> rbd info tmp
>> rbd image 'tmp':
>>     size 10240 MB in 2560 objects
>>     order 22 (4096 KB objects)
>>     block_name_prefix: rb.0.12dd.238e1f29
>>     format: 1
>> rbd map tmp
>> mkfs.ext4 /dev/rbd1
>> mount /dev/rbd1 /mnt
>> blockdev --getsize64 /dev/rbd1
>> 10737418240
>> rbd resize --size 20000 tmp
>> blockdev --getsize64 /dev/rbd1
>> 10737418240
>> resize2fs /dev/rbd1
>> resize2fs 1.42 (29-Nov-2011)
>> The filesystem is already 2621440 blocks long.  Nothing to do!
>>
>> It does work after umounting:
>>
>> umount /mnt
>> blockdev --getsize64 /dev/rbd1
>> fsck -f /dev/rbd1
>> resize2fs /dev/rbd1
>> resize2fs 1.42 (29-Nov-2011)
>> Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
>> The filesystem on /dev/rbd1 is now 5120000 blocks long.
>>
>> I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?
>>
>> Cheers
>>
> -- 
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: krbd & live resize

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

Hi,

Tried on another machine running

 3.8.0-25-generic #37~precise1-Ubuntu SMP

and the behavior is the same.

Cheers

On 30/07/2013 11:57, Loic Dachary wrote:
> 
> 
> On 30/07/2013 11:55, Laurent Barbe wrote:
>> Hello Loic,
>>
>> which version of kernel do you use for krbd ?
> 
> Linux i-csnces-0000 3.2.0-41-generic #66-Ubuntu SMP
> 
> That may explain a few things ... :-)
> 
>>
>> Laurent
>>
>>
>> Le 29/07/2013 23:50, Loic Dachary a écrit :
>>> Hi,
>>>
>>> This works:
>>>
>>> lvcreate --name tmp --size 10G all
>>>    Logical volume "tmp" created
>>> mkfs.ext4 /dev/all/tmp
>>> mount /dev/all/tmp /mnt
>>> blockdev --getsize64 /dev/all/tmp
>>> 10737418240
>>> lvextend -L+1G /dev/all/tmp
>>>    Extending logical volume tmp to 11,00 GiB
>>>    Logical volume tmp successfully resized
>>> blockdev --getsize64 /dev/all/tmp
>>> 11811160064
>>> resize2fs /dev/all/tmp
>>> resize2fs 1.41.12 (17-May-2010)
>>> Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
>>> old desc_blocks = 1, new_desc_blocks = 1
>>> Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
>>> The filesystem on /dev/all/tmp is now 2883584 blocks long.
>>>
>>> This does not work:
>>>
>>> rbd create --size 10240 tmp
>>> rbd info tmp
>>> rbd image 'tmp':
>>>     size 10240 MB in 2560 objects
>>>     order 22 (4096 KB objects)
>>>     block_name_prefix: rb.0.12dd.238e1f29
>>>     format: 1
>>> rbd map tmp
>>> mkfs.ext4 /dev/rbd1
>>> mount /dev/rbd1 /mnt
>>> blockdev --getsize64 /dev/rbd1
>>> 10737418240
>>> rbd resize --size 20000 tmp
>>> blockdev --getsize64 /dev/rbd1
>>> 10737418240
>>> resize2fs /dev/rbd1
>>> resize2fs 1.42 (29-Nov-2011)
>>> The filesystem is already 2621440 blocks long.  Nothing to do!
>>>
>>> It does work after umounting:
>>>
>>> umount /mnt
>>> blockdev --getsize64 /dev/rbd1
>>> fsck -f /dev/rbd1
>>> resize2fs /dev/rbd1
>>> resize2fs 1.42 (29-Nov-2011)
>>> Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
>>> The filesystem on /dev/rbd1 is now 5120000 blocks long.
>>>
>>> I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?
>>>
>>> Cheers
>>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: krbd & live resize

[Laurent Barbe]

Live resize has been added in 3.6.10 for krbd client.

There is a need to do revalidate_disk() on rbd resize :
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d98df63ea7e87d5df4dce0cece0210e2a777ac00

Cheers

Laurent


Le 30/07/2013 11:57, Loic Dachary a écrit :
>
>
> On 30/07/2013 11:55, Laurent Barbe wrote:
>> Hello Loic,
>>
>> which version of kernel do you use for krbd ?
>
> Linux i-csnces-0000 3.2.0-41-generic #66-Ubuntu SMP
>
> That may explain a few things ... :-)
>
>>
>> Laurent
>>
>>
>> Le 29/07/2013 23:50, Loic Dachary a écrit :
>>> Hi,
>>>
>>> This works:
>>>
>>> lvcreate --name tmp --size 10G all
>>>     Logical volume "tmp" created
>>> mkfs.ext4 /dev/all/tmp
>>> mount /dev/all/tmp /mnt
>>> blockdev --getsize64 /dev/all/tmp
>>> 10737418240
>>> lvextend -L+1G /dev/all/tmp
>>>     Extending logical volume tmp to 11,00 GiB
>>>     Logical volume tmp successfully resized
>>> blockdev --getsize64 /dev/all/tmp
>>> 11811160064
>>> resize2fs /dev/all/tmp
>>> resize2fs 1.41.12 (17-May-2010)
>>> Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
>>> old desc_blocks = 1, new_desc_blocks = 1
>>> Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
>>> The filesystem on /dev/all/tmp is now 2883584 blocks long.
>>>
>>> This does not work:
>>>
>>> rbd create --size 10240 tmp
>>> rbd info tmp
>>> rbd image 'tmp':
>>>      size 10240 MB in 2560 objects
>>>      order 22 (4096 KB objects)
>>>      block_name_prefix: rb.0.12dd.238e1f29
>>>      format: 1
>>> rbd map tmp
>>> mkfs.ext4 /dev/rbd1
>>> mount /dev/rbd1 /mnt
>>> blockdev --getsize64 /dev/rbd1
>>> 10737418240
>>> rbd resize --size 20000 tmp
>>> blockdev --getsize64 /dev/rbd1
>>> 10737418240
>>> resize2fs /dev/rbd1
>>> resize2fs 1.42 (29-Nov-2011)
>>> The filesystem is already 2621440 blocks long.  Nothing to do!
>>>
>>> It does work after umounting:
>>>
>>> umount /mnt
>>> blockdev --getsize64 /dev/rbd1
>>> fsck -f /dev/rbd1
>>> resize2fs /dev/rbd1
>>> resize2fs 1.42 (29-Nov-2011)
>>> Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
>>> The filesystem on /dev/rbd1 is now 5120000 blocks long.
>>>
>>> I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?
>>>
>>> Cheers
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: krbd & live resize

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]

Hi Laurent,

Thanks for the solution !

On 30/07/2013 12:07, Laurent Barbe wrote:
> Live resize has been added in 3.6.10 for krbd client.
> 
> There is a need to do revalidate_disk() on rbd resize :
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d98df63ea7e87d5df4dce0cece0210e2a777ac00
> 
> Cheers
> 
> Laurent
> 
> 
> Le 30/07/2013 11:57, Loic Dachary a écrit :
>>
>>
>> On 30/07/2013 11:55, Laurent Barbe wrote:
>>> Hello Loic,
>>>
>>> which version of kernel do you use for krbd ?
>>
>> Linux i-csnces-0000 3.2.0-41-generic #66-Ubuntu SMP
>>
>> That may explain a few things ... :-)
>>
>>>
>>> Laurent
>>>
>>>
>>> Le 29/07/2013 23:50, Loic Dachary a écrit :
>>>> Hi,
>>>>
>>>> This works:
>>>>
>>>> lvcreate --name tmp --size 10G all
>>>>     Logical volume "tmp" created
>>>> mkfs.ext4 /dev/all/tmp
>>>> mount /dev/all/tmp /mnt
>>>> blockdev --getsize64 /dev/all/tmp
>>>> 10737418240
>>>> lvextend -L+1G /dev/all/tmp
>>>>     Extending logical volume tmp to 11,00 GiB
>>>>     Logical volume tmp successfully resized
>>>> blockdev --getsize64 /dev/all/tmp
>>>> 11811160064
>>>> resize2fs /dev/all/tmp
>>>> resize2fs 1.41.12 (17-May-2010)
>>>> Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
>>>> old desc_blocks = 1, new_desc_blocks = 1
>>>> Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
>>>> The filesystem on /dev/all/tmp is now 2883584 blocks long.
>>>>
>>>> This does not work:
>>>>
>>>> rbd create --size 10240 tmp
>>>> rbd info tmp
>>>> rbd image 'tmp':
>>>>      size 10240 MB in 2560 objects
>>>>      order 22 (4096 KB objects)
>>>>      block_name_prefix: rb.0.12dd.238e1f29
>>>>      format: 1
>>>> rbd map tmp
>>>> mkfs.ext4 /dev/rbd1
>>>> mount /dev/rbd1 /mnt
>>>> blockdev --getsize64 /dev/rbd1
>>>> 10737418240
>>>> rbd resize --size 20000 tmp
>>>> blockdev --getsize64 /dev/rbd1
>>>> 10737418240
>>>> resize2fs /dev/rbd1
>>>> resize2fs 1.42 (29-Nov-2011)
>>>> The filesystem is already 2621440 blocks long.  Nothing to do!
>>>>
>>>> It does work after umounting:
>>>>
>>>> umount /mnt
>>>> blockdev --getsize64 /dev/rbd1
>>>> fsck -f /dev/rbd1
>>>> resize2fs /dev/rbd1
>>>> resize2fs 1.42 (29-Nov-2011)
>>>> Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
>>>> The filesystem on /dev/rbd1 is now 5120000 blocks long.
>>>>
>>>> I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?
>>>>
>>>> Cheers
>>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

-- 
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: krbd & live resize

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

Hi Laurent,

Your patch can be applied to 3.8 as described here:

http://dachary.org/?p=2179

Thanks again

On 30/07/2013 12:07, Laurent Barbe wrote:
> Live resize has been added in 3.6.10 for krbd client.
> 
> There is a need to do revalidate_disk() on rbd resize :
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d98df63ea7e87d5df4dce0cece0210e2a777ac00
> 
> Cheers
> 
> Laurent
> 
> 
> Le 30/07/2013 11:57, Loic Dachary a écrit :
>>
>>
>> On 30/07/2013 11:55, Laurent Barbe wrote:
>>> Hello Loic,
>>>
>>> which version of kernel do you use for krbd ?
>>
>> Linux i-csnces-0000 3.2.0-41-generic #66-Ubuntu SMP
>>
>> That may explain a few things ... :-)
>>
>>>
>>> Laurent
>>>
>>>
>>> Le 29/07/2013 23:50, Loic Dachary a écrit :
>>>> Hi,
>>>>
>>>> This works:
>>>>
>>>> lvcreate --name tmp --size 10G all
>>>>     Logical volume "tmp" created
>>>> mkfs.ext4 /dev/all/tmp
>>>> mount /dev/all/tmp /mnt
>>>> blockdev --getsize64 /dev/all/tmp
>>>> 10737418240
>>>> lvextend -L+1G /dev/all/tmp
>>>>     Extending logical volume tmp to 11,00 GiB
>>>>     Logical volume tmp successfully resized
>>>> blockdev --getsize64 /dev/all/tmp
>>>> 11811160064
>>>> resize2fs /dev/all/tmp
>>>> resize2fs 1.41.12 (17-May-2010)
>>>> Filesystem at /dev/all/tmp is mounted on /mnt; on-line resizing required
>>>> old desc_blocks = 1, new_desc_blocks = 1
>>>> Performing an on-line resize of /dev/all/tmp to 2883584 (4k) blocks.
>>>> The filesystem on /dev/all/tmp is now 2883584 blocks long.
>>>>
>>>> This does not work:
>>>>
>>>> rbd create --size 10240 tmp
>>>> rbd info tmp
>>>> rbd image 'tmp':
>>>>      size 10240 MB in 2560 objects
>>>>      order 22 (4096 KB objects)
>>>>      block_name_prefix: rb.0.12dd.238e1f29
>>>>      format: 1
>>>> rbd map tmp
>>>> mkfs.ext4 /dev/rbd1
>>>> mount /dev/rbd1 /mnt
>>>> blockdev --getsize64 /dev/rbd1
>>>> 10737418240
>>>> rbd resize --size 20000 tmp
>>>> blockdev --getsize64 /dev/rbd1
>>>> 10737418240
>>>> resize2fs /dev/rbd1
>>>> resize2fs 1.42 (29-Nov-2011)
>>>> The filesystem is already 2621440 blocks long.  Nothing to do!
>>>>
>>>> It does work after umounting:
>>>>
>>>> umount /mnt
>>>> blockdev --getsize64 /dev/rbd1
>>>> fsck -f /dev/rbd1
>>>> resize2fs /dev/rbd1
>>>> resize2fs 1.42 (29-Nov-2011)
>>>> Resizing the filesystem on /dev/rbd1 to 5120000 (4k) blocks.
>>>> The filesystem on /dev/rbd1 is now 5120000 blocks long.
>>>>
>>>> I assume there should be "something" in KRBD to allow for the same behavior as with LVM but I don't know enough about the kernel to be more specific. Maybe something similar to ioctl BLKRRPART ?
>>>>
>>>> Cheers
>>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

-- 
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]