2010/9/9 Zhu Yanhai <zhu.yanhai@xxxxxxxxx>: > 2010/9/9 Marcel Lohmann <marcel.lohmann@xxxxxxxxxxxxxx>: >> 2010/9/8 Zhu Yanhai <zhu.yanhai@xxxxxxxxx>: >>> Hi, >>> Have you ever tried with 'mkfs.btrfs -m single /dev/xxxx'? >>> As you had a RAID1 based on LVM, you don't have to keep >>> the default duplicated metadata profile in Btrfs. >>> >> No, I did not try this. I just created it with the defaults >> "mkfs.btrfs /dev/mapper/somelogicalvolume". Isn't "-m single" the >> default? > > No, it's not by default. Btrfs will write two copies of the Metadata into > disk by default, with only one copy of Data -- something similar with > RAID1, but not the same. > Anyway, you don't need this, since you already have a standard RAID1 > array setup by LVM. > '-m single' makes Btrfs write exactly one copy of Metadata, instead of > two by default. > To set this thread to SOLVED: I recreated the filesystem with "mkfs.btrfs -m single -d single /dev/mapper/xxx" and mounted it "compress"ed. After copying only 12,000,000 small files I have 5.13GB in Data and 15.15GB in Metadata. This is far away from good, but this is better than before. I can live with that because the estimated number of final files will be 60,000,000 which should fit well on the partition. > 53 * 2 + 24 = 130. The size of Metadata reported by "btrfs filesystem df" > is 53GB, however it occupies 53 * 2 = 106GB on 'disk' physically. > So yes, there will be more space for Data. There really IS more space for Data. 15.15 * 1 + 5.13 < 130. And yes this size is also reported by "df -h" Trying to use "-l 2048" during mkfs was rejected as being invalid. But who cares...? Marcel -- 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
