linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: frustrations with handling of crash reports
Date: Wed, 18 Jun 2014 21:22:50 +0000 (UTC)	[thread overview]
Message-ID: <pan$d2b51$8d2a30e2$29b90599$a8fc24d9@cox.net> (raw)
In-Reply-To: 53A192B8.2040601@gmail.com

Konstantinos Skarlatos posted on Wed, 18 Jun 2014 16:23:04 +0300 as
excerpted:

> I guess that btrfs developers have put these BUG_ONs so that they get
> reports from users when btrfs gets in these unexpected situations. But
> if most of these reports are ignored or not resolved, then maybe there
> is no use for these BUG_ONs and they should be replaced with something
> more mild.
> 
> Keep in mind that if a system panics, then the only way to get logs from
> it is with serial or netconsole, so BUG_ON really makes it much harder
> for users to know what happened and send reports, and only the most
> technical and determined users will manage to send reports here.

In terms of the BUGONs, they've been converting them to WARNONs recently, 
exactly due to the point you and Marc have made.  Not being a dev and 
simply based on the patch-flow I've seen as btrfs has been basically 
behaving itself so far here[1], I had /thought/ that was more or less 
done (perhaps some really bad bug-ons left but only a few, and basically 
only where the kernel couldn't be sure it was in a logical enough state 
to continue writing to other filesystems too, so bugon being logical in 
that case), but based on you guys' comments there's apparently more to go.

So at least for BUGONs they agree.  I guess it's simply a matter of 
getting them all converted.

Tho at least in Marc's case, he's running kernels a couple back in some 
cases and they may still have BUGONs already replaced in the most current 
kernel.

As for experimental, they've been toning down and removing the warnings 
recently.  Yes, the on-device format may come with some level of 
compatibility guarantee now so I do agree with that bit, but IMO anyway, 
that warning should be being replaced with a more explicit "on-device-
format is now stable but the code is not yet entirely so, so keep your 
backups and be prepared to use them, and run current kernels", language, 
and that's not happening, they're mostly just toning it down without the 
still explicit warnings, ATM.

---
[1] Btrfs (so far) behaving itself here: Possibly because my filesystems 
are relatively small and I don't use snapshots much and prefer several 
smaller independent filesystems rather than doing subvolumes, thus 
keeping the number of eggs in a single basket small.  Plus, with small 
filesystems on SSD, I can balance reasonably regularly, and I do full 
fresh mkfs.btrfs rounds every few kernels as well to take advantage of 
newer features, which may well have the result of killing smaller 
problems that aren't yet showing up before they get big enough to cause 
real issues.  Anyway, I'm not complaining! =:^)

-- 
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


  reply	other threads:[~2014-06-18 21:23 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
2014-06-18 13:23       ` Konstantinos Skarlatos
2014-06-18 21:22         ` Duncan [this message]
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='pan$d2b51$8d2a30e2$29b90599$a8fc24d9@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).