Hi Peter, > All of this is *very* surprising. I'm not new to BTRFS, I've been > using it on my own machines for multiple years. I didn't realise there > was an un-holstered footgun on my lap at this point. How can it be > made clear how to avoid the ENOSPC problem to myself and other > sysadmins? Or preferably not exist as a problem?
I've also found the fixed metadata/data split to be an uncomfortable implementation detail, and some more flexible approach would be very welcome from my side. So far I've used BTRFS' mixed mode mentioned in the mkfs.btrfs man page: > -M|--mixedMix data and metadata chunks together for more efficient space > utilization. > This feature incurs a performance penalty in larger filesystems. > It is recommended for use with filesystems of 1 GiB or smaller. However I didn't find any information on how large the mentioned overhead is, or where it originates from. Best regards, Clemens -- 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
