From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com ([74.125.82.41]:49949 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751286AbdKAAhu (ORCPT ); Tue, 31 Oct 2017 20:37:50 -0400 Received: by mail-wm0-f41.google.com with SMTP id b189so1970886wmd.4 for ; Tue, 31 Oct 2017 17:37:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <23033.512.820691.680916@tree.ty.sabi.co.uk> References: <20170831070558.GB5783@rus.uni-stuttgart.de> <20170912162843.GA32233@rus.uni-stuttgart.de> <20170914133824.5cf9b59c@jupiter.sol.kaishome.de> <20170914172434.39eae89d@jupiter.sol.kaishome.de> <59BBB15E.8010002@sarach.com.pl> <59BBDFA6.4020500@sarach.com.pl> <20170915190826.1f0be8a9@jupiter.sol.kaishome.de> <23033.512.820691.680916@tree.ty.sabi.co.uk> From: Dave Date: Tue, 31 Oct 2017 20:37:27 -0400 Message-ID: Subject: Re: defragmenting best practice? To: Linux fs Btrfs Cc: Peter Grandi Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Tue, Oct 31, 2017 at 7:06 PM, Peter Grandi wrote: > > Also nothing forces you to defragment a whole filesystem, you > can just defragment individual files or directories by using > 'find' with it. Thanks for that info. When defragmenting individual files on a BTRFS filesystem with COW, I assume reflinks between that file and all snapshots are broken. So if there are 30 snapshots on that volume, that one file will suddenly take up 30 times more space... Is that correct? Or are the reflinks only broken between the live file and the latest snapshot? Or is it something between, based on how many times the file has changed? > > 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 That's a very helpful example. Can you also give an example of using find, as you suggested above? I'm generally familiar with using find to execute specific commands, but an example is appreciated in this case. > > 2. Put $HOME/.cache on a separate BTRFS subvolume that is mounted nocow -- it will NOT be snapshotted > 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. Thanks for your reply. I appreciate any other feedback or suggestions. Background: I'm not sure why our Firefox performance is so terrible but here's my original post from Sept 20. (I could repost the earlier replies too if needed.) I've been waiting to have a window of opportunity to try to fix our Firefox performance again, and now I have that chance. >On Thu 2017-08-31 (09:05), Ulli Horlacher wrote: >> When I do a >> btrfs filesystem defragment -r /directory >> does it defragment really all files in this directory tree, even if it >> contains subvolumes? >> The man page does not mention subvolumes on this topic. > >No answer so far :-( > >But I found another problem in the man-page: > > Defragmenting with Linux kernel versions < 3.9 or >= 3.14-rc2 as well as > with Linux stable kernel versions >= 3.10.31, >= 3.12.12 or >= 3.13.4 > will break up the ref-links of COW data (for example files copied with > cp --reflink, snapshots or de-duplicated data). This may cause > considerable increase of space usage depending on the broken up > ref-links. > >I am running Ubuntu 16.04 with Linux kernel 4.10 and I have several >snapshots. >Therefore, I better should avoid calling "btrfs filesystem defragment -r"? > >What is the defragmenting best practice? >Avoid it completly? My question is the same as the OP in this thread, so I came here to read the answers before asking. Based on the answers here, it sounds like I should not run defrag at all. However, I have a performance problem I need to solve, so if I don't defrag, I need to do something else. Here's my scenario. Some months ago I built an over-the-top powerful desktop computer / workstation and I was looking forward to really fantastic performance improvements over my 6 year old Ubuntu machine. I installed Arch Linux on BTRFS on the new computer (on an SSD). To my shock, it was no faster than my old machine. I focused a lot on Firefox performance because I use Firefox a lot and that was one of the applications in which I was most looking forward to better performance. I tried everything I could think of and everything recommended to me in various forums (except switching to Windows) and the performance remained very disappointing. Then today I read the following: Gotchas - btrfs Wiki https://btrfs.wiki.kernel.org/index.php/Gotchas Fragmentation: Files with a lot of random writes can become heavily fragmented (10000+ extents) causing excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM. On desktops this primarily affects application databases (including Firefox). Workarounds include manually defragmenting your home directory using btrfs fi defragment. Auto-defragment (mount option autodefrag) should solve this problem. Upon reading that I am wondering if fragmentation in the Firefox profile is part of my issue. That's one thing I never tested previously. (BTW, this system has 256 GB of RAM and 20 cores.) Furthermore, on the same BTRFS Wiki page, it mentions the performance penalties of many snapshots. I am keeping 30 to 50 snapshots of the volume that contains the Firefox profile. Would these two things be enough to turn top-of-the-line hardware into a mediocre-preforming desktop system? (The system performs fine on benchmarks -- it's real life usage, particularly with Firefox where it is disappointing.) After reading the info here, I am wondering if I should make a new subvolume just for my Firefox profile(s) and not use COW and/or not keep snapshots on it and mount it with the autodefrag option. As part of this strategy, I could send snapshots to another disk using btrfs send-receive. That way I would have the benefits of snapshots (which are important to me), but by not keeping any snapshots on the live subvolume I could avoid the performance problems. What would you guys do in this situation?