Re: Using BTRFS on SSD now ?

[Duncan <1i5t5.duncan@cox.net>]

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