Robert White posted on Wed, 10 Dec 2014 02:53:40 -0800 as excerpted: > On 12/09/2014 05:08 PM, Dongsheng Yang wrote: >> On 12/10/2014 02:47 AM, Goffredo Baroncelli wrote: >>> Hi Dongsheng On 12/09/2014 12:20 PM, Dongsheng Yang wrote: >>>> When function btrfs_statfs() calculate the tatol size of fs, it is >>>> calculating the total size of disks and then dividing it by a factor. >>>> But in some usecase, the result is not good to user. >>>> >>>> Example: >>>> # mkfs.btrfs -f /dev/vdf1 /dev/vdf2 -d raid1 >>>> # mount /dev/vdf1 /mnt >>>> # dd if=/dev/zero of=/mnt/zero bs=1M count=1000 >>>> # df -h /mnt >>>> Filesystem Size Used Avail Use% Mounted on >>>> /dev/vdf1 3.0G 1018M 1.3G 45% /mnt >>>> >>>> # btrfs fi show /dev/vdf1 >>>> Label: none uuid: f85d93dc-81f4-445d-91e5-6a5cd9563294 >>>> Total devices 2 FS bytes used 1001.53MiB >>>> devid 1 size 2.00GiB used 1.85GiB path /dev/vdf1 >>>> devid 2 size 4.00GiB used 1.83GiB path /dev/vdf2 >>>> >>>> a. df -h should report Size as 2GiB rather than as 3GiB. >>>> Because this is 2 device raid1, the limiting factor is devid 1 @2GiB. >>> I agree > > NOPE. > > The model you propose is too simple. > > While the data portion of the file system is set to RAID1 the metadata > portion of the filesystem is still set to the default of DUP.
Metadata defaults to DUP only on a single-device filesystem. On a multi- device filesystem, metadata defaults to raid1. (FWIW, for both, data defaults to single.) And in the example, the mkfs was supplied with two devices, so there's no dup metadata remaining from a formerly single-device filesystem, either. (Tho there will be the small single-mode stubs, empty, remaining from the mkfs process, as no balance has been run to delete them yet, but those are much smaller and empty.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
