On 2017-11-01 21:39, Dave wrote:
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?
The easiest option is to just make sure nobody is logged in and run the
following shell script fragment:
for dir in /home/* ; do
rm -rf $dir/.cache
btrfs subvolume create $dir/.cache
done
And then add something to the user creation scripts to create that
subvolume. This approach won't pollute /etc/fstab, will still exclude
the directory from snapshots, and doesn't require any hugely creative
work to integrate with user creation and deletion.
In general, the contents of the .cache directory are just that, cached
data. Provided nobody is actively accessing it, it's perfectly safe to
just nuke the entire directory (I actually do this on a semi-regular
basis on my systems just because it helps save space). In fact, based
on the FreeDesktop.org standards, if this does break anything, it's a
bug in the software in question.
--
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
