From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Filesystem will remount read-only
Date: Fri, 16 Sep 2016 23:18:03 +0000 (UTC) [thread overview]
Message-ID: <pan$d74d4$cbd69fcd$ef8693ee$7eb1227f@cox.net> (raw)
In-Reply-To: 8AC4324B47948D40A1031D5AB7D077820141E77717@mailstore.skyward.com
Jeffrey Michels posted on Fri, 16 Sep 2016 14:57:43 +0000 as excerpted:
> Hello,
>
> I have a system that has been in production for a few years. The SAN
> the VM was running on had a hardware failure about a month ago and now
> one of the two btrfs filesystems will remount after boot read-only.
> Here is the system information:
>
> uname -a
>
> Linux retain 3.0.101-0.47.71-default #1 SMP Thu Nov 12 12:22:22 UTC 2015
> (b5b212e) x86_64 x86_64 x86_64 GNU/Linux
>
> Btrfs --version
>
> Btrfs v0.20+
That is positively /ancient/, both kernel and userspace (btrfs-progs).
Keep in mind that btrfs was still considered very experimental back then,
with the experimental labels coming off only with 3.14 or there abouts,
IIRC (userspace releases got version-synced with kernelspace in 3.12, so
3.14 applies to both).
So you have been running an at-the-time still extremely experimental
filesystem for years now, and it's only now coming up with problems that
need fixed. Pretty remarkable for the experimental state back then, but
it doesn't change the fact that it /was/ "may eat your data and burn your
kids alive as a sacrifice to appease the filesystem gods" level
experimental, with the according warnings, back then.
So first thing I'd suggest is to update to kernel 4.4 LTS series, and
something similar for btrfs-progs userspace. Then, given the age and
experimental nature of the filesystem back then, I'd kill the filesystems
and do a fresh mkfs.btrfs, restoring from backups. That way you're
starting with a well tested and stable LTS kernel that is both reasonably
mature already, and will be supported for some time to come, and
eliminate any possibility of long fixed and forgotten bugs coming back to
bite you years later.
Alternatively, if you're using a long-term support distro, you have the
choice of going to them for that support, since unlike this list which
focuses on the state going forward, that sort of deep long-term support
of long outdated versions is a good part of the reason such distros
exist, and a good part of why a lot of people are willing to pay
sometimes rather sizable sums of money /for/ that level of support.
--
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
next prev parent reply other threads:[~2016-09-16 23:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 14:57 Filesystem will remount read-only Jeffrey Michels
2016-09-16 23:18 ` Duncan [this message]
2016-09-17 0:08 ` Chris Murphy
2016-09-17 0:56 ` Chris Murphy
2016-09-21 15:24 ` Jeffrey Michels
2016-09-21 15:49 ` 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='pan$d74d4$cbd69fcd$ef8693ee$7eb1227f@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).