On Tuesday 01 Sep 2015 05:49:14 Chandan Rajendra wrote: > On Monday 31 Aug 2015 14:11:27 Theodore Ts'o wrote: > > On Sun, Aug 30, 2015 at 08:16:21PM +0530, Chandan Rajendra wrote: > > > For small filesystem instances (i.e. size <= 1 GiB), mkfs.btrfs fails > > > when > > > "data block size" does not match with the "metadata block size" > > > specified > > > on the mkfs.btrfs command line. This commit increases the size of > > > filesystem instance created so that the test can be executed on > > > subpagesize-blocksize Btrfs instances which have different values for > > > data and metadata blocksizes. > > > > Stupid question --- why isn't this considered a bug in mkfs.btrfs? > > Does btrfs simply not support file systems <= 1 GB? So if someone has > > a 1GB USB disk or SD card, what's the official advice from the btrfs > > developers? Use xfs or ext4? > > Ted, Btrfs does indeed support filesystem instances <= 1GiB. When creating > such instances, mixed block groups are created i.e. These block groups hold > both data and metadata. Hence the requirement of having matching "data block > size" and "metadata block size" for filesystems <= 1 GiB. > > mkfs.btrfs when invoked on small filesystems by "not" specifying any block > sizes (i.e. mkfs.btrfs -f /dev/sda1) will automatically create filesystem > instance with "data block size" == "metadata block size". However in the > subpagesize-blocksize scenario, we need to specify both data and metadata > block size on the command line (For e.g. mkfs.btrfs -f -s 4096 -n 16384 > /dev/sda1). In this case, Since the user is forcing the block sizes and it > is impossible to have mixed block groups with differing data and metadata > block sizes, mkfs.btrfs will fail. Also, For small filesystems, "mkfs.btrfs -f /dev/sda1 -s 4096 -n 4096" works fine since the command is invoked with the same size for both data and metadata blocks. -- chandan -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
