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
