* krbd & live resize
@ 2013-07-29 21:50 Loic Dachary
2013-07-30 9:55 ` Laurent Barbe
0 siblings, 1 reply; 7+ messages in thread
From: Loic Dachary @ 2013-07-29 21:50 UTC (permalink / raw)
To: Ceph Development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: krbd & live resize
2013-07-29 21:50 krbd & live resize Loic Dachary
@ 2013-07-30 9:55 ` Laurent Barbe
2013-07-30 9:57 ` Loic Dachary
0 siblings, 1 reply; 7+ messages in thread
From: Laurent Barbe @ 2013-07-30 9:55 UTC (permalink / raw)
To: Loic Dachary; +Cc: Ceph Development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: krbd & live resize
2013-07-30 9:55 ` Laurent Barbe
@ 2013-07-30 9:57 ` Loic Dachary
2013-07-30 10:03 ` Loic Dachary
2013-07-30 10:07 ` Laurent Barbe
0 siblings, 2 replies; 7+ messages in thread
From: Loic Dachary @ 2013-07-30 9:57 UTC (permalink / raw)
To: Laurent Barbe; +Cc: Ceph Development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: krbd & live resize
2013-07-30 9:57 ` Loic Dachary
@ 2013-07-30 10:03 ` Loic Dachary
2013-07-30 10:07 ` Laurent Barbe
1 sibling, 0 replies; 7+ messages in thread
From: Loic Dachary @ 2013-07-30 10:03 UTC (permalink / raw)
To: Laurent Barbe; +Cc: Ceph Development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: krbd & live resize
2013-07-30 9:57 ` Loic Dachary
2013-07-30 10:03 ` Loic Dachary
@ 2013-07-30 10:07 ` Laurent Barbe
2013-07-30 11:01 ` Loic Dachary
2013-07-30 13:40 ` Loic Dachary
1 sibling, 2 replies; 7+ messages in thread
From: Laurent Barbe @ 2013-07-30 10:07 UTC (permalink / raw)
To: Loic Dachary; +Cc: Ceph Development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: krbd & live resize
2013-07-30 10:07 ` Laurent Barbe
@ 2013-07-30 11:01 ` Loic Dachary
2013-07-30 13:40 ` Loic Dachary
1 sibling, 0 replies; 7+ messages in thread
From: Loic Dachary @ 2013-07-30 11:01 UTC (permalink / raw)
To: Laurent Barbe; +Cc: Ceph Development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: krbd & live resize
2013-07-30 10:07 ` Laurent Barbe
2013-07-30 11:01 ` Loic Dachary
@ 2013-07-30 13:40 ` Loic Dachary
1 sibling, 0 replies; 7+ messages in thread
From: Loic Dachary @ 2013-07-30 13:40 UTC (permalink / raw)
To: Laurent Barbe; +Cc: Ceph Development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-07-30 13:40 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-29 21:50 krbd & live resize Loic Dachary
2013-07-30 9:55 ` Laurent Barbe
2013-07-30 9:57 ` Loic Dachary
2013-07-30 10:03 ` Loic Dachary
2013-07-30 10:07 ` Laurent Barbe
2013-07-30 11:01 ` Loic Dachary
2013-07-30 13:40 ` Loic Dachary
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.