From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Migrate to bcache: A few questions
Date: Fri, 3 Jan 2014 00:09:26 +0000 (UTC) [thread overview]
Message-ID: <pan$6af1d$ed6b6a3b$ad28a0c4$aecbe1eb@cox.net> (raw)
In-Reply-To: 52C55D36.2070201@gmail.com
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
prev parent reply other threads:[~2014-01-03 0:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-29 21:11 Migrate to bcache: A few questions Kai Krakow
2013-12-30 1:03 ` Chris Murphy
2013-12-30 1:22 ` Kai Krakow
2013-12-30 3:48 ` Chris Murphy
2013-12-30 9:01 ` Marc MERLIN
2013-12-31 0:31 ` Kai Krakow
2013-12-30 6:24 ` Duncan
2013-12-31 3:13 ` Kai Krakow
2013-12-30 16:02 ` Austin S Hemmelgarn
2014-01-01 10:06 ` Duncan
2014-01-01 20:12 ` Austin S Hemmelgarn
2014-01-02 8:49 ` Duncan
2014-01-02 12:36 ` Austin S Hemmelgarn
2014-01-03 0:09 ` Duncan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$6af1d$ed6b6a3b$ad28a0c4$aecbe1eb@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).