Re: How btrfs resize should work ?
On Fri, Aug 16, 2013 at 02:11:23PM -0600, Chris Murphy wrote: On Aug 16, 2013, at 12:02 PM, Chris Murphy li...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How btrfs resize should work ?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How btrfs resize should work ?
On Aug 16, 2013, at 10:30 AM, Zach Brown z...@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 lczer...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How btrfs resize should work ?
On Aug 16, 2013, at 12:02 PM, Chris Murphy li...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
