> I'm following up on all the suggestions regarding Firefox performance
> on BTRFS. [ ... ]

I haven't read that yet, so maybe I am missing something, but I
use Firefox with Btrfs all the time and I haven't got issues.

[ ... ]
> 1. BTRFS snapshots have proven to be too useful (and too important to
>    our overall IT approach) to forego.
[ ... ]
> 3. We have large amounts of storage space (and can add more), but not
>    enough to break all reflinks on all snapshots.

Firefox profiles get fragmented only in the databases containes
in them, and they are tiny, as in dozens of MB. That's usually
irrelevant.

Also nothing forces you to defragment a whole filesystem, you
can just defragment individual files or directories by using
'find' with it.

My top "$HOME" fragmented files are the aKregator RSS feed
databases, usually a few hundred fragments each, and the
'.sqlite' files for Firefox. Occasionally like just now I do
this:

  tree$  sudo filefrag .firefox/default/*.sqlite | sort -t: -k 2n | tail -4
  .firefox/default/cleanup.sqlite: 43 extents found
  .firefox/default/content-prefs.sqlite: 67 extents found
  .firefox/default/formhistory.sqlite: 87 extents found
  .firefox/default/places.sqlite: 3879 extents found

  tree$  sudo btrfs fi defrag .firefox/default/*.sqlite

  tree$  sudo filefrag .firefox/default/*.sqlite | sort -t: -k 2n | tail -4
  .firefox/default/webappsstore.sqlite: 1 extent found
  .firefox/default/favicons.sqlite: 2 extents found
  .firefox/default/kinto.sqlite: 2 extents found
  .firefox/default/places.sqlite: 44 extents found

> 2. Put $HOME/.cache on a separate BTRFS subvolume that is mounted
> nocow -- it will NOT be snapshotted

The cache can be simply deleted, and usually files in it are not
updated in place, so don't get fragmented, so no worry.

Also, you can declare the '.firefox/default/' directory to be
NOCOW, and that "just works". I haven't even bothered with that.
--
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

Reply via email to