All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
To: "Jörn Engel" <joern@logfs.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Jeff Moyer <jmoyer@redhat.com>,
	Steve Hodgson <steve@purestorage.com>
Subject: Re: [PATCH] add blockconsole version 1.1
Date: Tue, 24 Jul 2012 09:01:16 +0100	[thread overview]
Message-ID: <201207240901.16151.tvrtko.ursulin@onelan.co.uk> (raw)
In-Reply-To: <20120723200230.GC17767@logfs.org>

On Monday 23 Jul 2012 21:02:30 Jörn Engel wrote:
> On Mon, 23 July 2012 15:33:16 +0100, Tvrtko Ursulin wrote:
> > On Thursday 12 Jul 2012 18:46:34 Jörn Engel wrote:
> > > Console driver similar to netconsole, except it writes to a block
> > > device.  Can be useful in a setup where netconsole, for whatever
> > > reasons, is impractical.
> > 
> > Perhaps you need to add a word or two about limitations compared to
> > netconsole in documentation because it is quite significant difference
> > in reliability? I mean so it is not assumed it is analogous to
> > netconsole but just a different underlying media. I don't know if
> > someone would expect it, but better said than not.
> 
> Given that I don't even know the limitations, that's a bit tough.  As
> a general rule, I would always prefer netconsole.  It appears to be
> more reliable than blockconsole and beats serial console by half a
> lightyear.  But as a fallback when netconsole is not realistic,
> blockconsole has proven useful.

At the very least block console does not work from interrupt context while 
netconsole does, right? Also netconsole does things to try and work around low 
memory situations. Things like that I think would be useful additions to 
documentation.
 
> > I second the notion that logging to partitions would be useful.
> 
> Below is a compile-tested patch to do that.  Feel free to give it a
> spin and fix any bugs.

I can't promise to do that in the very near future, but in principle idea 
could be interesting to me, at least to evaluate how reliable mechanism is 
with different storage interfaces and controllers.

> > Also, and I haven't checked what the swap format is, if it could somehow
> > be integrated together that could be useful.
> 
> That appears to be slightly less likely than crossbreeding a rabbit
> with a chicken.  Is there something obvious I have missed?

I was thinking how swap space is always there and is potentially much faster 
to write to than a random USB stick - which could translate to more reliable. 
Then it's a question of which storage subsystem (libata vs. usb-storage) would 
work better in different oops/panic situations. Again I tend to have less hope 
in USB based solutions - maybe it's my bias from working in that area many 
years ago. So the idea of swap space was that _if_ swap format could be 
extended to allocate a number of blocks to use other than swap, then that area 
could be used by blockconsole. Seemed like a convenient and potentially more 
reliable solution to me, but as I said the latter may depend.

Tvrtko

  reply	other threads:[~2012-07-24  8:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 20:59 [RFC][PATCH] add blockconsole Jörn Engel
2012-04-25 13:42 ` Jeff Moyer
2012-04-25 13:25   ` Jörn Engel
2012-04-25 15:52     ` Jeff Moyer
2012-07-12 17:46       ` [PATCH] add blockconsole version 1.1 Jörn Engel
2012-07-13 13:03         ` Borislav Petkov
2012-07-13 16:20           ` Jörn Engel
2012-07-13 21:14             ` Borislav Petkov
2012-07-16 12:46             ` Borislav Petkov
2012-07-18 18:53               ` Jörn Engel
2012-07-18 21:45                 ` Borislav Petkov
2012-07-18 21:08                   ` Jörn Engel
2012-07-19  9:26                     ` Borislav Petkov
2012-07-23 20:04                   ` Jörn Engel
2012-07-24 15:42                     ` Borislav Petkov
2012-07-24 14:53                       ` Jörn Engel
2012-07-24 16:25                         ` Borislav Petkov
2012-07-24 17:52                           ` Jörn Engel
2012-07-24 20:28                             ` Borislav Petkov
2012-12-19 10:20                               ` Borislav Petkov
2012-08-14 11:54                 ` Jan Engelhardt
2012-07-23 14:33         ` Tvrtko Ursulin
2012-07-23 20:02           ` Jörn Engel
2012-07-24  8:01             ` Tvrtko Ursulin [this message]
2012-07-24 14:38               ` Jörn Engel
2012-07-25  8:17                 ` Tvrtko Ursulin
2012-07-25 16:39                   ` Jörn Engel

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=201207240901.16151.tvrtko.ursulin@onelan.co.uk \
    --to=tvrtko.ursulin@onelan.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=jmoyer@redhat.com \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steve@purestorage.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.