On Wed, Nov 1, 2017 at 8:21 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
>> 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. > > Yes, it will, and it will save space long-term as well since $HOME/.cache is > usually the most frequently modified location in $HOME. In addition to not > including this in the snapshots, it may also improve performance. Each > subvolume is it's own tree, with it's own locking, which means that you can > generally improve parallel access performance by splitting the workload > across multiple subvolumes. Whether it will actually provide any real > benefit in that respect is heavily dependent on the exact workload however, > but it won't hurt performance. I'm going to make this change now. What would be a good way to implement this so that the change applies to the $HOME/.cache of each user? The simple way would be to create a new subvolume for each existing user and mount it at $HOME/.cache in /etc/fstab, hard coding that mount location for each user. I don't mind doing that as there are only 4 users to consider. One minor concern is that it adds an unexpected step to the process of creating a new user. Is there a better way? -- 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
