The patch is here: http://patchwork.kernel.org/patch/81547/ , it's for kernel. But I have just seen weird behaviour with my btrfs, I'm not sure whether it's my patch or the new changes I have pulled from git - I'd recommend you wait with trying out this patch until someone diagnoses what failed with my fs :-) And as for metadata size - "btrfs-vol -b" reduces the metadata amount by a large amount for filesystems containing huge files. On Wed, Feb 24, 2010 at 8:20 PM, Boyd Waters <waters.boyd@xxxxxxxxx> wrote: > Thanks for the suggestions, everyone! > > I copied the data from the 2TB btrfs disk to an identical disk (same > make and model) formatted with ext4: > > /dev/sdi2 1.9T 1.7T 197G 90% /media/onlyhope > /dev/sdg1 1.8T 1.7T 71G 96% /mnt/newhope > > The metadata "overhead" for btrfs is a bit more, but it isn't outrageous IMHO. > > == > > Re-balancing the tree with "btrfs-vol -b" sounds about right, both in > terms of time and stability. I haven't tried that yet, but I can > report on that experiment. > > Leszek wrote: >> The 'used' output of df on a btrfs system does not take metadata into > account. So the disk is really full. This is what my yesterdays path > is intended to fix - can you try it out? >> > > I would like to try this patch, I apologize for being so new to btrfs > development: can you tell me where to find the patch? Is it for btrfs > tools or the btrfs itself? I will try to find it, but a quick pointer > to it will help me test! > > Thanks again! > -- > 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 > -- 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
