Hendrik Friedel posted on Mon, 24 Mar 2014 21:52:09 +0100 as excerpted: >> But regardless of my experience with my own usage pattern, I suspect >> that with reasonable monitoring, you'll eventually become familiar with >> how fast the chunks are allocated and possibly with what sort of >> actions beyond the obvious active moving stuff around on the filesystem >> triggers those allocations, for your specific usage pattern, and can >> then adapt as necessary. > > Yes, that's a workaround. But really, that makes one the slave to your > filesystem. That's not really acceptable, is it?
Well, given the relative immaturity of btrfs as a filesystem at this point in its lifetime, I think it's acceptable/tolerable. However, for a filesystem feted[1] to ultimately replace the ext* series as an assumed Linux default, I'd definitely argue that the current situation should be changed such that btrfs can automatically manage its own de-allocation at some point, yes, and that said "some point" really needs to come before that point at which btrfs can be considered an appropriate replacement for ext2/3/4 as the assumed default Linux filesystem of the day. --- [1] feted: celebrated, honored. I had to look it up to be sure my intuition on usage was correct, and indeed I had spelled it wrong (fetted). Yay for online wictionary and google-define! =:^) Anyway, for others who may not be familiar with the term, since I have the links open ATM: http://en.wiktionary.org/wiki/feted https://www.google.com/search?q=define:feted -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
