On 12/13/2014 08:50 AM, Duncan wrote:
Goffredo Baroncelli posted on Fri, 12 Dec 2014 19:00:20 +0100 as
excerpted:
$ sudo ./btrfs fi df /mnt/btrfs1/
Data, RAID1: total=1.00GiB, used=512.00KiB
Data, single: total=8.00MiB, used=0.00B
System, RAID1: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, RAID1: total=1.00GiB, used=112.00KiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=16.00MiB, used=0.00B
In this case the filesystem is empty (it was a new filesystem !).
However a 1G metadata chunk was already allocated. This is the reasons
why the free space is only 4Gb.
Trivial(?) correction.
Metadata chunks are quarter-gig, not 1 gig. So that's 4 quarter-gig
metadata chunks allocated, not a (one/single) 1-gig metadata chunk.
Sorry but from my reading of the code, I have to say that in this case
it is 1G.
Maybe I should be wrong, I would say, yes, the chunk_size for btrfs which is
smaller than 50G is 256M by default. But in mkfs, we alloc 1G for the first
metadata chunk.
On my system the ratio metadata/data is 234MB/8.82GB = ~3%, so ignoring
the metadata chunk from the free space may not be a big problem.
Presumably your use-case is primarily reasonably large files; too large
for their data to be tucked directly into metadata instead of allocating
an extent from a data chunk.
That's not always going to be the case. And given the multi-device
default allocation of raid1 metadata, single data, files small enough to
fit into metadata have a default size effect double their actual size!
(Tho it can be noted that given btrfs' 4 KiB standard block size, without
metadata packing there'd still be an outsized effect for files smaller
than half that, 2 KiB or under, but there it'd be in data chunks, not
metadata.)
--
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
