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@xxxxxxxxxxxxxxx >> 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:
signature.asc
Description: OpenPGP digital signature