Re: defragmenting best practice?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-11-01 21:39, Dave wrote:
> On Wed, Nov 1, 2017 at 8:21 AM, Austin S. Hemmelgarn
> <ahferroin7@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.