Am Montag, 4. August 2014, 11:09:23 schrieb Peter Waller: > On 4 August 2014 10:39, Chris Samuel <ch...@csamuel.org> wrote: > > On Mon, 4 Aug 2014 09:14:19 AM Peter Waller wrote: > >> All of this is *very* surprising. > > > > Hmm, it shouldn't be, the ENOSPC issues are well known and have been > > discussed here for years. > > I accept that. It's all very well if you read the BTRFS list and/or > are a BTRFS developer. But if you're trying to work it out in the heat > of battle, as we have sysadmins who would have to, there is a > combination of things here that makes it unreasonable and harmful for > production.
Well, maybe, just maybe… BTRFS is not yet ready for production use. I installed it on a server recently, my own VM. And I am expect that I may need to fix up things there. And I did it with a *huge* free space margin. And still running Debian backport kernel 3.14. Won´t change it to 3.16 until I have seen that it runs nicely on my laptop again. Test it on non critical servers – yes. Use it on critical production servers? My answer is a no for this. Despite partial support in SLES 11 SP 2 and support (partial?) for it in Oracle Unbreakable Linux. BTRFS is just not yet there from my current experiences with it. One thing that may get you covered up usually: Make it five times as large as the data you put on it and try to monitor for situation you better rebalance in advance. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
