> When defragmenting individual files on a BTRFS filesystem with
> COW, I assume reflinks between that file and all snapshots are
> broken. So if there are 30 snapshots on that volume, that one
> file will suddenly take up 30 times more space... [ ... ]
Defragmentation works by effectively making a copy of the file
contents (simplistic view), so the end result is one copy with
29 reflinked contents, and one copy with defragmented contents.
> Can you also give an example of using find, as you suggested
> above? [ ... ]
Well, one way is to use 'find' as a filtering replacement for
'defrag' option '-r', as in for example:
find "$HOME" -xdev '(' -name '*.sqlite' -o -name '*.mk4' ')' \
-type f -print0 | xargs -0 btrfs fi defrag
Another one is to find the most fragmented files first or all
files of at least 1M with with at least say 100 fragments as in:
find "$HOME" -xdev -type f -size +1M -print0 | xargs -0 filefrag \
| perl -n -e 'print "$1\0" if (m/(.*): ([0-9]+) extents/ && $1 > 100)' \
| xargs -0 btrfs fi defrag
But there are many 'find' web pages and that is not quite a
Btrfs related topic.
> [ ... ] The easiest way I know to exclude cache from
> BTRFS snapshots is to put it on a separate subvolume. I assumed this
> would make several things related to snapshots more efficient too.
Only slightly.
> Background: I'm not sure why our Firefox performance is so terrible
As I always say, "performance" is not the same as "speed", and
probably your Firefox "performance" is sort of OKish even if the
"speed" is terrile, and neither is likely related to the profile
or the cache being on Btrfs: most JavaScript based sites are
awfully horrible regardless of browser:
http://www.sabi.co.uk/blog/13-two.html?130817#130817
and if Firefox makes a special contribution it tends to leak
memory on several odd but common cases:
https://utcc.utoronto.ca/~cks/space/blog/web/FirefoxResignedToLeaks?showcomments
Plus it tends to cache too much, e.g. recently close tabs.
But Firefox is not special because most web browsers are not
designed to run for a long time without a restart, and
Chromium/Chrome simply have a different set of problem sites.
Maybe the new "Quantum" Firefox 57 will improve matters because
it has a far more restrictive plugin API.
The overall problem is insoluble, hipster UX designers will be
the second the the wall when the revolution comes :-).
--
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
