From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wido den Hollander Subject: Re: Ceph doesn't update the block device size while a rbd image is mounted Date: Thu, 19 Jul 2012 17:47:07 +0200 Message-ID: <50082BFB.9000605@widodh.nl> References: <50082476.4020109@widodh.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp01.mail.pcextreme.nl ([109.72.87.137]:48487 "EHLO smtp01.mail.pcextreme.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852Ab2GSPrI (ORCPT ); Thu, 19 Jul 2012 11:47:08 -0400 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: =?ISO-8859-1?Q?S=E9bastien_Han?= Cc: ceph-devel On 19-07-12 17:26, S=E9bastien Han wrote: > Ok I got your point seems logic, but why is this possible with LVM fo= r example? > > You can easily do this with LVM without un-mounting the device. > LVM runs through the device mapper and are not regular block devices. If you resize the disk underneath LVM you won't see an increased VG or=20 PV size unless you change the availability of the VG to unavailable and= =20 back to available again. I'm not a 100% sure what the exact root cause is, but the kernel won't=20 read the new size of a block device as long as it is in use. Wido > Cheers. > > > On Thu, Jul 19, 2012 at 5:15 PM, Wido den Hollander = wrote: >> Hi, >> >> >> On 19-07-12 16:55, S=E9bastien Han wrote: >>> >>> Hi Cephers! >>> >>> I'm working with rbd mapping. I figured out that the block device s= ize >>> of the rbd device is not update while the device is mounted. Here m= y >>> tests: >>> >> >> iirc this is not something RBD specific, but since the device is in = use it >> can't be re-read by the kernel. >> >> So when you unmount it the kernel can re-read the header and resize = the >> device. >> >> Wido >> >>> 1. Pick up a device and check his size >>> >>> # rbd ls >>> size >>> >>> # rbd info test >>> rbd image 'test': >>> size 10000 MB in 2500 objects >>> order 22 (4096 KB objects) >>> block_name_prefix: rb.0.6 >>> parent: (pool -1) >>> >>> 2. Map the device >>> >>> # rbd map --secret /etc/ceph/secret test >>> # rbd showmapped >>> id pool image snap device >>> 1 rbd test - /dev/rbd1 >>> >>> 3. Put a fs on it and check the block device size >>> >>> # mkfs.ext4 /dev/rdb1 >>> ... >>> ... >>> >>> # fdisk -l /dev/rbd1 >>> >>> Disk /dev/rbd1: 10.5 GB, 10485760000 bytes >>> >>> 4. Mount it >>> >>> # mount /dev/rbd1 /mnt >>> # df -h >>> /dev/rbd1 9.8G 277M 9.0G 3% /mnt >>> >>> >>> 5. Change the image size >>> >>> # rbd resize --size 11000 test >>> Resizing image: 100% complete...done. >>> >>> # rbd info test >>> rbd image 'test': >>> size 11000 MB in 2750 objects >>> order 22 (4096 KB objects) >>> block_name_prefix: rb.0.6 >>> parent: (pool -1) >>> >>> At this point of time, if you perform the fdisk -l /dev/rbd1, the >>> block device size will remain the same. >>> >>> 6. Unmount the device: >>> >>> # umount /media >>> >>> # fdisk -l /dev/rbd1 >>> Disk /dev/rbd1: 11.5 GB, 11534336000 bytes >>> >>> Unmounting the directory did update the block device size. >>> >>> Of course you can do something really fast like: >>> >>> # umount /media && mount /dev/rbd1 /media >>> >>> That will work, it's a valid solution as long as there is no opened >>> file. I won't use this trick in production... >>> >>> I also tried to "mount -o remount" and it didn't work. >>> >>> 7. Resize the fs (this can be performed while the fs is mounted): >>> >>> # e2fsck -f /dev/rbd1 >>> e2fsck 1.42 (29-Nov-2011) >>> Pass 1: Checking inodes, blocks, and sizes >>> Pass 2: Checking directory structure >>> Pass 3: Checking directory connectivity >>> Pass 4: Checking reference counts >>> Pass 5: Checking group summary information >>> /dev/rbd1: 11/644640 files (0.0% non-contiguous), 77173/2560000 blo= cks >>> >>> # resize2fs /dev/rbd1 >>> resize2fs 1.42 (29-Nov-2011) >>> Resizing the filesystem on /dev/rbd1 to 2816000 (4k) blocks. >>> The filesystem on /dev/rbd1 is now 2816000 blocks long. >>> >>> >>> Did I miss something? >>> Is this feature coming? >>> >>> Thank you in advance :) >>> -- >>> To unsubscribe from this list: send the line "unsubscribe ceph-deve= l" 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" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html