Austin S Hemmelgarn posted on Thu, 02 Jan 2014 07:36:06 -0500 as excerpted:
> 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). I went ahead with the gentoo tree and overlays on SSD, because... well, they need the fast access that SSD provides, and if I can't use the SSD for its good points, why did I buy it in the first place? It's also worth noting that only a few files change on a day to day basis. Most of the tree remains as it is. Similarly with the git pack files behind the overlays (and live-git sources) -- once they reach a certain point they stop changing and all the changes go into a new file. Further, most reports I've seen suggest that daily changes on some reasonably small part of an SSD aren't a huge problem... given wear- leveling and an estimated normal lifetime of say three to five years before they're replaced with new hardware anyway, daily changes simply shouldn't be an issue. It's worth keeping limited-write-cycles in mind and minimizing them where possible, but it's not quite the big thing a lot of people make it out to be. Additionally, I'm near 100% overprovisioned, giving the SSDs lots of room to do that wear-leveling, so... Meanwhile, are you using tail packing on that ext4? The idea of wasting all that space due to all those small files has always been a downer for me and others, and is the reason many of us used reiserfs for many years. I guess ext4 now does have tail packing or some similar solution, but I do wonder how much that tail packing affects performance. Of course it'd also be possible to run reiserfs without tail packing, and even without journaling. But somehow I always thought what was the point of running reiser, if those were disabled. Anyway, I'd find it interesting to benchmark what the effect of tailpacking (or whatever ext4 calls it) on no-journal ext4 for the gentoo tree actually was. If you happen to know, or happen to be inspired to run those benchmarks now, I'd be interested... > 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. With 16 gig RAM, won't the sync have pulled everything into page-cache already? That has always seemed to be the case here. Running an emerge --deep --upgrade --newuse @world here after a sync shows very little disk activity and takes far less time than trying the same thing after an unmount/remount, thus cold-cache. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
