> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
