| |||||||||||||
Btrfs: broken by design?Btrfs: broken by design?Posted Jun 27, 2010 12:28 UTC (Sun) by nix (subscriber, #2304)In reply to: Btrfs: broken by design? by NRArnot Parent article: Btrfs: broken by design?
True. But the amount of space consumed by metadata is horrifying to me. 40%+ of your disk capacity eaten by metadata? What the hell? The only FS I've ever seen that was this bad before was Coda (and actually that was fairly trim, at roughly 5% metadata overhead: it was just that all the metadata for the whole filesystem was mmap()ed in at all times, a bit problematic on a 32-bit system...)
(some of us also have hardware RAID so every byte spent backing up metadata is a byte wasted, but I'm sure btrfs can turn that off: and admittedly this is not a common case.)
(Log in to post comments)
Btrfs: broken by design? Posted Jun 27, 2010 21:48 UTC (Sun) by dark (subscriber, #8483) [Link] Hmm, where are you getting the 40% number? Is that real metadata, or are the inline extents also counted as metadata because they are stored in leaf nodes?
Btrfs: broken by design? Posted Jun 27, 2010 22:02 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
in the mail thread the btrfs author stated this figure (20% in metadata that is then replicated)
Btrfs: broken by design? Posted Jun 27, 2010 23:02 UTC (Sun) by nix (subscriber, #2304) [Link]
I think it might even have been higher than that, 46% or something, but I could remember it was above 40%.
Btrfs: broken by design? Posted Jun 29, 2010 20:26 UTC (Tue) by masoncl (subscriber, #47138) [Link]
Everything being stored is in metadata blocks (the btree) but this does include the actual file data. The test chose file sizes that btrfs would pack into the btree.
|
|||||||||||||