From: Robert White <rwhite@pobox.com>
To: Peter Volkov <pva@gentoo.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs stuck with lot's of files
Date: Mon, 01 Dec 2014 10:47:44 -0800 [thread overview]
Message-ID: <547CB7D0.4040800@pobox.com> (raw)
In-Reply-To: <1417434411.20237.1.camel@gentoo.org>
On 12/01/2014 03:46 AM, Peter Volkov wrote:
> Hi, guys.
> (stuff about getting hung up trying to write to one drive)
That drive (/dev/sdn) is probably starting to fail. Some older drives
basically go unresponsive when they start to go bad. Particularly if
they've gone bad enough to have run out of spare tracks/sectors.
Sometimes they will just refuse to answer. Sometimes they will go into
"try again" mode, and the same activity will be retried indefinitely.
This will then fill up your write queues and jam up all sorts of subsystems.
Step 1: Backup your data. Since you didn't RAID your data at all, when
that drive dies your data is going to go away in fascinating and
unpredictable ways. (RAID1 metadata with no RAID1 or RAID5 of the data
means you have essentially no media failure protection.)
Step 2: Turn on SMART (if you can and you can) and check whether the
drive is in its final moments of life. If your disk is all green lights
according to smart, you may be able to un-jamb it by just doing a
balance as described and explained after the next time I quote you.
Step 3: Switch your data mode to RAID5. It will cost you about half of
your currenly free data space, but it won't leave you _as_ _vulnerable_
to complete data loss as you are now. SMART might be wrong about your
drive being fine if it says it is.
> # btrfs filesystem df /store/
> Data, single: total=11.92TiB, used=10.86TiB
Reguardless of the above...
You have a terabyte of unused but allocated data storage. You probably
need to balance your system to un-jamb that. That's a lot of space that
is unavailable to the metadata (etc).
ASIDE: Having your metadata set to RAID1 (as opposed to the default of
DUP) seems a little iffy since your data is still set to DUP. This
configuration is not going to leave you with a mountable filesystem if
you lose a disk. I'm not sure if the RAID1 layout is going to want to
put specific datum in specific places, but it might, which if it does
might leave you in an irreconcilable position.
Either way, you will probably un-jam your system in the short run by
doing a balance. A full balance (no filter args at all) would be your
best bet.
FUTHER ASIDE: raid1 metadata and raid5 data might be good for you given
22 volumes and 10% empty empty space it would only cost you half of your
existing empty space. If you don't RAID your data, there is no real
point to putting your metadata in RAID.
[Yes, I said my basic points about your current layout two different
ways and times. You are either "just a little over-committed on space"
or you are "about to lose all your data" and it's impossible to tell
which is the case from here.]
Backup your data. NOW!
next prev parent reply other threads:[~2014-12-01 18:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 11:46 btrfs stuck with lot's of files Peter Volkov
2014-12-01 18:47 ` Robert White [this message]
2014-12-02 1:50 ` Peter Volkov
2014-12-02 12:48 ` Duncan
2014-12-02 18:56 ` Ian Armstrong
2014-12-02 22:42 ` Duncan
2014-12-02 1:33 ` Qu Wenruo
2014-12-02 2:00 ` Peter Volkov
2014-12-04 22:58 ` Reiterate: " Peter Volkov
2014-12-04 23:55 ` Chris Murphy
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=547CB7D0.4040800@pobox.com \
--to=rwhite@pobox.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=pva@gentoo.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