On 2014-01-02 03:49, Duncan wrote: > Austin S Hemmelgarn posted on Wed, 01 Jan 2014 15:12:40 -0500 as > excerpted: > >> On 12/30/2013 11:02 AM, Austin S Hemmelgarn wrote: >>> >>> As an alternative to using bcache, you might try something simmilar to >>> the following: >>> 64G SSD with /boot, /, and /usr Other HDD with /var, /usr/portage, >>> /usr/src, and /home tmpfs or ramdisk for /tmp and /var/tmp >>> This is essentially what I use now, and I have found that it >>> significantly improves system performance. >>> >> On this specific note, I would actually suggest against putting the >> portage tree on btrfs, it makes syncing go ridiculously slow, >> and it also seems to slow down emerge as well. > > Interesting observation. > > I had not see it here (with the gentoo tree and overlays on btrfs), but > that's very likely because all my btrfs are on SSD, as I upgraded to both > at the same time, because my previous default filesystem choice, > reiserfs, isn't well suited to SSD due to excessive writing due to the > journaling. > > I do know slow syncs and portage dep-calculations were one of the reasons > I switched to SSD (and thus btrfs), however. That was getting pretty > painful on spinning rust, at least with reiserfs. And I imagine btrfs on > single-device spinning rust would if anything be worse at least for > syncs, due to the default dup metadata, meaning at least three writes > (and three seeks) for each file, once for the data, twice for the > metadata. > I think the triple seek+write is probably the biggest offender in my case, although COW and autodefrag probably don't help either. I'm kind of hesitant to put stuff that gets changed daily on a SSD, so I've ended up putting portage on ext4 with no journaling (which out-performs every other filesystem I have tested WRT write performance). As for the dep-calculations, I have 16G of ram, so I just use a script to read the entire tree into the page cache after each sync. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
