Le lundi 12 septembre 2016, 08:20:20 Austin S. Hemmelgarn a écrit : > FWIW, here's a list of what I personally consider stable (as in, I'm > willing to bet against reduced uptime to use this stuff on production > systems at work and personal systems at home): > 1. Single device mode, including DUP data profiles on single device > without mixed-bg. > 2. Multi-device … raid1, … with symmetrical > devices (all devices are the same size). > 4. Small numbers (max double digit) of snapshots, taken at infrequent > intervals (no more than once an hour). I use single snapshots regularly > to get stable images of the filesystem for backups, and I keep hourly > ones of my home directory for about 48 hours. > 5. Subvolumes used to isolate parts of a filesystem from snapshots. I > use this regularly to isolate areas of my filesystems from backups. > 6. Non-incremental send/receive (no clone source, no parent's, no > deduplication). I use this regularly for cloning virtual machines. > 7. Checksumming and scrubs using any of the profiles I've listed above. > 8. Defragmentation, including autodefrag. > 9. All of the compat_features, including no-holes and skinny-metadata.
I would also agree that all this is perfectly stable in my own experience. (I removed above what I didn’t personnally use, or didn’t use long enough to vouch for it). > Things I consider stable enough that I'm willing to use them on my > personal systems but not systems at work: > 1. In-line data compression with compress=lzo. I use this on my laptop > and home server system. I've never had any issues with it myself, but I > know that other people have, and it does seem to make other things more > likely to have issues. I never had problems with lzo compression, although I suspect that it (in conjuction with snapshots) adds much fragmentation that may relate to the extremely bad performance I get over time with mechanical HDs. > 2. Batch deduplication. Every time I tried to use any of the available dedup tools, either it immediately failed miserably, or it failed after eating all of my machine’s RAM. It didn’t eat my data, although. My 2 cents… -- Michel Bouissou <michel.bouis...@umontpellier.fr> Ingénieur Systèmes Université de Montpellier - DSIN -- 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
