All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
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 10:38:22 -0400	[thread overview]
Message-ID: <20120724143822.GA24954@logfs.org> (raw)
In-Reply-To: <201207240901.16151.tvrtko.ursulin@onelan.co.uk>

On Tue, 24 July 2012 09:01:16 +0100, Tvrtko Ursulin wrote:
> 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:
> 
> 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.

Blockconsole does work from interrupt context.  It has buffers for 1MB
worth of data.  Until those fill up, it only does a memcpy and
schedules a workqueue for writeback.  If you panic, it will do the
writeback immediately.  While I wouldn't believe this to always work,
I have yet to see a confirmed failure case.

Blockconsole itself has no allocations in the write path, so it should
be unaffected by low memory situation.  The underlying driver and
block layer code may well be.

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

Fair enough.  In the meantime I will leave this code out.  Adding a
new interface that noone has tested would be pretty bad style.

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

In my systems swap is often absent.  Plus, taking a few blocks a swap
aside is in the end just partitioning in a new dress.  So the argumen
appears to boil down to using partitions again.  The equivalent of
swap files might be interesting, but can also be somewhat scary.  So I
would leave it to others to actually write the code - if they care.

Libata is fine, blockconsole can work on any block device.

Jörn

--
Anything that can go wrong, will.
-- Finagle's Law

  reply	other threads:[~2012-07-24 15:52 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
2012-07-24 14:38               ` Jörn Engel [this message]
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=20120724143822.GA24954@logfs.org \
    --to=joern@logfs.org \
    --cc=akpm@linux-foundation.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steve@purestorage.com \
    --cc=tvrtko.ursulin@onelan.co.uk \
    /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.