Chris Murphy posted on Sun, 21 Jul 2013 10:20:48 -0600 as excerpted: > On Jul 21, 2013, at 4:38 AM, Duncan <1i5t5.duncan@xxxxxxx> wrote: >> >> What I'd suggest is to turn on the btrfs autodefrag mount option, and >> to do it *BEFORE* you start installing stuff on the filesystem. > > Is there a good reason why autodefrag is not a default mount option? Well, there's the obvious, that btrfs is still in development, lacking such things as the ability to set such options by default using btrfs- tune, and likely with the question of what should be the defaults still unresolved for many cases. Autodefrag can also negatively affect performance especially if it's not on from the beginning, AND at least at one point earlier in btrfs evolution (I'm not sure if it's fixed now or not), the performance for very large and often written into files such as virtual-machine images and large databases was bad, since it could mean constantly rewriting entire large files instead of just the smaller changing pieces of them, thereby being a performance killer for that type of job load. >> I believe >> it's a known issue that a number of distro installers (what arch does >> I'm not sure) tend to fragment their files pretty badly right off the >> bat if you let them. This would happen if they write data into an >> existing file, perhaps because they install a package and then >> customize the config files, or if they don't write whole files at once. >> And a lot of btrfs installs don't turn on the autodefrag option when >> they do thet first auto- >> mount to install stuff. > > Some installer teams are understandably reluctant to use non-default > mount options. It's worth keeping in mind the bigger picture, tho, that in the case of btrfs they're using a still in development filesystem (even if it's not the default, the fact that so few people come here unaware of the wiki or btrfs status as a development filesystem IMO indicates that installers aren't including the warnings about making such even non-default choices that they arguably should be including) where all recommendations are to be ready for loss of data should it occur, as it's a definitely more likely possibility than it should be with a stable filesystem. With that in mind, playing with non-default mount options seems rather trivial by comparison. Still, the previously mentioned constantly written large vm/db file use- case is a big one these days, and with the general purpose installation often not having dedicated partitions for such things (btrfs subvolumes don't yet allow per-subvolume setting of such options)... But for the generally much different use-case of a system volume where all the system binaries and config is stored, autodefrag makes a lot of sense to enable by default. Or installers could simply be better about not writing into existing files in the installation in the first place, so people could turn it on right after installation and not have to worry about existing fragmentation. But... installing to btrfs is really a reasonably new situation, and I'd guess "best practices" are still evolving just as the filesystem itself is. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
