From: Bill Williamson <bill@bbqninja.com>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs mounts RO, kernel oops on RW
Date: Sun, 28 May 2017 17:27:47 +1000 [thread overview]
Message-ID: <CAHPjZW5sRxns7CN8QmhB_HaQP5PGo7smFrf+q1QWHRRVnAToMA@mail.gmail.com> (raw)
In-Reply-To: <pan$3ce02$7e425613$62194897$37882c38@cox.net>
On 28 May 2017 at 15:56, Duncan <1i5t5.duncan@cox.net> wrote:
> Bill Williamson posted on Sun, 28 May 2017 12:46:00 +1000 as excerpted:
>
>> At first I got the failed to read log tree error, so I ran
>> btrfs-zero-log. It walked back 3-4 transactions but now seems okay.
>>
>> After that fix:
>> - btrfs check shows no errors.
>> - mounting the filesystem RO works great, I can read files.
>> - mounting the filesystem RW results in a huge kernel exception and a
>> hang, centering around can_overcommit and
>> btrfs_async_reclaim_metadata_space
>
> Try using the skip_balance mount option. See the btrfs (5) manpage (you
> must specify the 5, or you'll get the section 8 general btrfs command
> manpage).
>
> If that works, you can resume or cancel the balance once the filesystem
> is mounted writable.
Thanks for the tip, but no joy :(
Exactly the same kernel oops.
> The sysadmin's first rule of backups: The value of your data is defined
> by the number and currency of your backups: No backups, you are defining
> your data as of only trivial value, worth less than the time/trouble/
> resources necessary to make those backups. (In)Actions speak louder than
> words, so the definition holds regardless of any after-the-fact protests
> to the contrary.
Thanks also for the backup reinforcement here, as it made me double
check everything I have in place. The important data (photos etc) is
backed up in a few different places and will be easy to restore. The
only thing that wasn't in those backups is our minecraft world saves,
so they are now backed up too :)
The rest of the data is the typical "family" stuff, as in a rip of
every blu ray/dvd we own, a lot of tv shows, etc. So stuff that is
all replaceable, but annoys the kids that it will be gone for a short
while. Eg not worth spending $$$ on a like for like backup regime.
> (The second rule of backups is that a would-be backup isn't a backup
> until you've tested it restorable/usable. Until then, it's only a would-
> be backup, as the backup simply isn't complete until it has been tested.)
Also a good reminder to check that my photos will restore from
elsewhere.... and they do.
> Meanwhile, turning the topic a bit, toward your suggested 8 TB drives.
> Be aware that many of those are archive-targeted drives and aren't
> designed for normal use.
I didn't consider that, as "most" of my data is semi-archival, but it
still gets moved around a bit. I was indeed considering the 8TB
archive hard drives you were thinking of, so thanks for the warning!
I'm not asking for a specific endorsement, but should I be considering
something like the seagate ironwolf or WD red drives?
Thanks again for the reply
BIll
next prev parent reply other threads:[~2017-05-28 7:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-28 2:46 btrfs mounts RO, kernel oops on RW Bill Williamson
2017-05-28 5:56 ` Duncan
2017-05-28 7:27 ` Bill Williamson [this message]
2017-05-28 20:51 ` Duncan
2017-05-29 8:39 ` Marat Khalili
2017-05-28 22:25 ` 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=CAHPjZW5sRxns7CN8QmhB_HaQP5PGo7smFrf+q1QWHRRVnAToMA@mail.gmail.com \
--to=bill@bbqninja.com \
--cc=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).