Am Tue, 31 Oct 2017 20:37:27 -0400 schrieb Dave <davestechs...@gmail.com>:
> > Also, you can declare the '.firefox/default/' directory to be > > NOCOW, and that "just works". > > The cache is in a separate location from the profiles, as I'm sure you > know. The reason I suggested a separate BTRFS subvolume for > $HOME/.cache is that this will prevent the cache files for all > applications (for that user) from being included in the snapshots. We > take frequent snapshots and (afaik) it makes no sense to include cache > in backups or snapshots. 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. > > As far as the Firefox profile being declared NOCOW, as soon as we take > the first snapshot, I understand that it will become COW again. So I > don't see any point in making it NOCOW. Ah well, not really. The files and directories will still be nocow - however, the next write to any such file after a snapshot will make a cow operation. So you still see the fragmentation effect but to a much lesser extent. But the files itself will remain in nocow format. You may want to try btrfs autodefrag mount option and see if it improves things (tho, the effect may take days or weeks to apply if you didn't enable it right from the creation of the filesystem). Also, autodefrag will probably unshare reflinks on your snapshots. You may be able to use bees[1] to work against this effect. Its interaction with autodefrag is not well tested but it works fine for me. Also, bees is able to reduce some of the fragmentation during deduplication because it will rewrite extents back into bigger chunks (but only for duplicated data). [1]: https://github.com/Zygo/bees -- Regards, Kai Replies to list-only preferred. -- 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
