Hi, I am working on system storage manager (ssm) trying to implement btrfs resize correctly, however I have some troubles with it. # mkfs.btrfs /dev/sda /dev/sdb # mount /dev/sda /mnt/test # btrfs filesystem show failed to open /dev/sr0: No medium found Label: none uuid: 8dce5578-a2bc-416e-96fd-16a2f4f770b7 Total devices 2 FS bytes used 28.00KB devid 2 size 50.00GB used 2.01GB path /dev/sdb devid 1 size 100.00GB used 2.03GB path /dev/sda Btrfs v0.20-rc1 # btrfs filesystem resize 3G /mnt/test # sync # btrfs filesystem show failed to open /dev/sr0: No medium found Label: none uuid: 8dce5578-a2bc-416e-96fd-16a2f4f770b7 Total devices 2 FS bytes used 796.00KB devid 2 size 50.00GB used 2.01GB path /dev/sdb devid 1 size 3.00GB used 2.03GB path /dev/sda So it appears that it only resized part of the file system which lies on /dev/sda to 3G. This behavior is confusing as hell, is this really desirable behaviour ? I do understand that you''re able to specify devid to resize, however without devid specification this kind of does not make any sense. dm get it right, and it also has several different policies on handling this stuff and it was not easy to get this right. Is btrfs going to fix this somehow, it does it expect user to take care of this (I hope not). Because currently ssm is not able to resize btrfs correctly. Thanks! -Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> So it appears that it only resized part of the file system which > lies on /dev/sda to 3G. This behavior is confusing as hell, is this > really desirable behaviour ?Yeah, ''btrfs filesystem resize'' is misnamed. It only resizes a specified device which defaults to devid 1 if you don''t specify one. The documentation is just tragically wrong: " filesystem resize [devid:][+/-]<size>[gkm]|[devid:]max <path> Resize a filesystem identified by <path> for the underlying device devid. " Nope.> fix this somehow, it does it expect user to take care of this (I > hope not). Because currently ssm is not able to resize btrfs > correctly.What *would* be correctly? What does ssm expect to be able to do with all of the devices under a file system after it is resized? Put another way: if you couldn''t inspect the btrfs metadata, what would a unit test for this look like that would pass? - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Aug 16, 2013, at 10:30 AM, Zach Brown <zab@redhat.com> wrote:>> So it appears that it only resized part of the file system which >> lies on /dev/sda to 3G. This behavior is confusing as hell, is this >> really desirable behaviour ? > > Yeah, ''btrfs filesystem resize'' is misnamed. It only resizes a > specified device which defaults to devid 1 if you don''t specify one.I think there shouldn''t be a default devid. If it''s not specified, it should fail. On Aug 16, 2013, at 2:19 AM, Lukáš Czerner <lczerner@redhat.com> wrote:> I do understand that you''re able to specify devid to resize, however > without devid specification this kind of does not make any sense. dm > get it right, and it also has several different policies on handling > this stuff and it was not easy to get this right. Is btrfs going to > fix this somehow, it does it expect user to take care of this (I > hope not). Because currently ssm is not able to resize btrfs > correctly.The Btrfs volume is like a combined VG/LV. So it seems to me it lacks the granularity to do what can be done with LVM. When I shrink resize an LV, its freed extents return to the VG without affecting the PV''s or their partitioning. When a Btrfs multiple device volume is shrunk resized, it directly affects the partition size which must also be changed as a separate operation right now. I don''t see Btrfs having the same granularity as LVM in this respect. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Aug 16, 2013, at 12:02 PM, Chris Murphy <lists@colorremedies.com> wrote:> When a Btrfs multiple device volume is shrunk resized, it directly affects the partition size…Oops, this obviously happens with single or multiple device. I also think the command needs to return some information about exactly where the end of the file system is, maybe in file system blocks? resize2fs states the number of fs blocks in the fs, after a resize. From that I can figure out the exact ending LBA needed when changing the partition table. Btrfs leaves me totally guessing what this value should be. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 16, 2013 at 02:11:23PM -0600, Chris Murphy wrote:> > On Aug 16, 2013, at 12:02 PM, Chris Murphy <lists@colorremedies.com> wrote: > > > When a Btrfs multiple device volume is shrunk resized, it directly affects the partition size… > > Oops, this obviously happens with single or multiple device. > > I also think the command needs to return some information about > exactly where the end of the file system is, maybe in file system > blocks? resize2fs states the number of fs blocks in the fs, after a > resize. From that I can figure out the exact ending LBA needed when > changing the partition table. Btrfs leaves me totally guessing what > this value should be.It should be possible to obtain the information from the device tree via the SEARCH_TREE ioctl. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html