From: Marc MERLIN <marc@merlins.org>
To: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, Chris Mason <clm@fb.com>
Subject: Re: frustrations with handling of crash reports
Date: Tue, 17 Jun 2014 11:27:45 -0700 [thread overview]
Message-ID: <20140617182745.GO19071@merlins.org> (raw)
In-Reply-To: <20140617145957.GH19071@merlins.org>
On Tue, Jun 17, 2014 at 07:59:57AM -0700, Marc MERLIN wrote:
> It is also ok to answer "Any FS created or used before kernel 3.x can be
> corrupted due to bugs we fixed in 3.y, thank you for your report but it's
> not a good use of our time to investigate this"
> (although newer kernels should not just crash with BUG(xxx) on unexpected
> data, they should remount the FS read only).
I was thinking about this some more, and I know I have no right to tell
others what to do, so take this as a mere suggestion :)
How about doing a release with cleanups and stabilization and better state
reporting when things go wrong?
This would give a good known version for users who have actual data and
backups that can take many hours or days to restore (never mind downtime).
A few things I was thinking about:
1) Wouldn't it be a good time to replace all the BUG ON statements with
appropriate error handling? Unexpected data can happen, the kernel shouldn't
crash that.
At the very least it should remount read only and give maybe a wiki link to
the user on what to do next (some bu reporting and recovery page)
2) On unexpected cases, output basic information on the filesystem or printk
instructions to the user on how to gather data that would be sent to the
list to be reviewed.
This would include information on how old the filesystem is when it's
possible to detect, and the instruction page could say "sorry, anything
older than X, we don't want to hear about, we already fixed corruption bugs
since then"
3) getting printk data on an end user machine when it just started refusing
to write to disk can be challenging and cause useful debug info to be lost.
Things I thinking about:
a) make sure most btrfs bugs do not just hang the kernel
b) recommend to users to send kernel syslog messages to an ext4 partition
How does that sound?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
next prev parent reply other threads:[~2014-06-17 18:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 13:49 3.15-rc5 deadlocked a 2nd time after I was copying photos from an sdcard + common code path that deadlocks all btrfs filesystems Marc MERLIN
2014-06-17 6:29 ` Satoru Takeuchi
2014-06-17 14:40 ` Marc MERLIN
2014-06-17 14:59 ` frustrations with handling of crash reports Marc MERLIN
2014-06-17 18:27 ` Marc MERLIN [this message]
2014-06-18 13:23 ` Konstantinos Skarlatos
2014-06-18 21:22 ` Duncan
2014-06-19 8:56 ` Konstantinos Skarlatos
2014-06-19 15:06 ` Duncan
2014-06-19 15:19 ` Duncan
2014-06-19 17:37 ` Chris Murphy
2014-06-19 15:13 ` Marc MERLIN
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=20140617182745.GO19071@merlins.org \
--to=marc@merlins.org \
--cc=clm@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=takeuchi_satoru@jp.fujitsu.com \
/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).