Chris Murphy posted on Thu, 05 Jun 2014 12:13:37 -0600 as excerpted: >> auto-defrag: not really (read the archives) > > Definitely there are some issues, it's probably why its not yet default. > So I'd either not use it, or use it with the point of testing it to make > it better. Usage-pattern is the big one with autodefrag. I'm personally an autodefrag user and booster, but my use-case has few if any of the big red-flag file-access-pattern cases, and several where there's reasonable benefit. Autodefrag's target: Small (up to a few hundred MiB, safely under a gig and preferably under half a gig) internal-rewrite-pattern files typically found on desktop/laptop purpose systems. Typical example: Firefox and thunderbird sqlite database files. Also: Multi-file simultaneous write, since this write pattern can trigger fragmentation as well, that autodefrag's background rewrite strategy should counter/fix. Autodefrag sees writes that update these files and on copy-on-write (COW) filesystems such as btrfs trigger fragmentation, and queues the affected files for background sequential rewrite and defrag. On this type of file this strategy works very well, neutralizing the fragmentation that would otherwise plague these files on btrfs, without huge ware or performance issues. Autodefrag's bane: Large (gig-plus) internal-rewrite-pattern files, traditionally less often found on desktop/laptop systems altho they are becoming more common. Typical examples: VM-images and database files over a gig in size. It can be noted that these types of files are a challenge for any COW- based filesystem, btrfs being no exception. Like me, you may have few to none of these, but if you do, I strongly recommend reading up on the NOCOW file attribute and related strategies, as it's very likely the single most common performance issue seen with btrfs, autodefrag or not and ssd or not. See the "Very slow filesystem" thread posted by Igor M (igork20 at gmail) yesterday. Autodefrag neutral: Sequentially-written files in general and append-only files such as the typical logfile, particularly when only one file is being written at once. Autodefrag strategy hint: If you choose to use this mount option, it's best to use it from THE FIRST TIME file data is written to the filesystem. Unfortunately, as of a year or so ago at least, various distro installers did NOT use this flag by default when installing on btrfs, resulting in a lot of out-of-the-box installation fragmentation on btrfs. Turning it on only after installation thus resulted in a performance drag for several days, until autodefrag caught up with the backlog. So if installing to btrfs, verify that this flag is turned on by the installer for the install itself, if necessary using the custom option at this step to turn it on at initial mount, before all those files are copied over by the installer. As an installation-time-autodefrag alternative, run btrfs filesystem defrag -r (recursive) on the filesystem after installation, before you start using it much and definitely before the first btrfs snapshot (or delete that snapshot first, do the defrag, then create a new snapshot). That will take care of all the fragmentation at once, and by doing it without snapshots taken, you avoid data duplication due to defrag being temporarily snapshot-aware disabled, until they fix the scaling issues that snapshot-awareness was triggering. Unless you have autodefrag-bane files to worry about (and if you do, I strongly recommend that you do your research on that and special-case them with NOCOW and etc), even on ssd, autodefrag should be a small bonus due to saved IOPS, tho not to the extent it would be on spinning rust due to ssd's zero-seek-time. -- 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
