How btrfs resize should work ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux