All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: "Paweł Brodacki" <pawel.brodacki@googlemail.com>
Cc: Alexander Lyakas <alex.bolshoy@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: [md PATCH 08/23] md: don't set md arrays to readonly on shutdown.
Date: Sun, 22 Apr 2012 06:42:03 +1000	[thread overview]
Message-ID: <20120422064203.65eee938@notabene.brown> (raw)
In-Reply-To: <CACVpCE6UZvBia2VwRMaFhJJuB2quvKKQc1byLFRP4YPTE8LHSQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

On Sat, 21 Apr 2012 17:18:58 +0200 Paweł Brodacki
<pawel.brodacki@googlemail.com> wrote:

> W dniu 20 kwietnia 2012 14:01 użytkownik NeilBrown <neilb@suse.de> napisał:
> > On Fri, 20 Apr 2012 13:30:39 +0200 Paweł Brodacki
> > <pawel.brodacki@googlemail.com> wrote:
> >>
> >> The way I read the message agrees with Alexander's perception. My
> >> impression from reading the commit message is, that normal shutdown
> >> may result in unclean array, which I would perceive as a regression.
> >
> > I don't think you'll find the word "normal" in the original message :-)
> >
> Neil, I respect you and admire your work and all, but I think you are
> having good time with us and this commit message, aren't you? :)

"For what, we ask, is life - without a touch of poetry in it".

Maybe not an entirely relevant quote, but it is the first that came to mind.

"What's life without whimsy?"

Would be a slightly more modern quote.

Can you place them without google's help?

> 
> >>
> >> I would really appreciate clear statement, whether this behaviour
> >> (writeback during shutdown, with possibility of poweroff/reboot while
> >> array is dirty) can or cannot occur during normal shutdown process.
> >
> > Define "normal".
> > If you kill any processes that could generate write-out, and then do a
> > 'sync', then everything should be fine.
> >
> I think "normal shutdown" can be defined for the purpose of this
> discussion as whatever /sbin/shutdown does.
> 
> If I run /sbin/shutdown -h now, it is a normal shutdown. If I do fancy
> stuff echoing cute strings and integers into various parts of /proc
> and /sys, push magic buttons and/or pull cables at random, it' is not
> a normal shutdown.
> 
> > I suspend a "normal" shutdown sequence does this.
> >
> > NeilBrown
> >
> 
> I smell a hint here.
> 
> man shutdown:
> "shutdown arranges for the system to be brought down in a safe way."
> Define safe...
> 
> Neil, could you point us to a bug report which inspired you to write
> this patch? My google fu failed me and I was able to find just one bug
> entry from before 2 yerars, and even that hit is of dubious relevance.
> 
> Pretty please with sugar on top?
> 

https://bugzilla.novell.com/show_bug.cgi?id=713148

But that is against our "enterprise" product so is not globally visible :-(

But it gave me some search-term hints so:

http://lists.debian.org/debian-kernel/2011/05/msg00264.html

http://www.issociate.de/board/post/491554/Kernel_BUG.html

http://www.gossamer-threads.com/lists/xen/devel/174884?do=post_view_threaded

https://lkml.org/lkml/2008/11/24/414
http://comments.gmane.org/gmane.linux.raid/20710

The important elements are:
 1/ you see "md: stopping all devices".  This means that "reboot" has 
   really started.  This is printed by mds reboot notifier.

 2/ A stack trace showing something submitting IO.
   In the first link it is bdi_writeback_task
   In the second it is kjournald

This pattern can only happen on an unclean shutdown.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-04-21 20:42 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14  4:40 [md PATCH 00/23] md patches heading for 3.4 NeilBrown
2012-03-14  4:40 ` [md PATCH 05/23] md/raid5: use atomic_dec_return() instead of atomic_dec() and atomic_read() NeilBrown
2012-03-14  4:40 ` [md PATCH 06/23] md: allow last device to be forcibly removed from RAID1/RAID10 NeilBrown
2012-03-14  4:40 ` [md PATCH 01/23] md/raid5: make sure reshape_position is cleared on error path NeilBrown
2012-03-14  4:40 ` [md PATCH 04/23] md: Use existed macros instead of numbers NeilBrown
2012-03-14  4:40 ` [md PATCH 03/23] md/raid5: removed unused 'added_devices' variable NeilBrown
2012-03-14  4:40 ` [md PATCH 02/23] md/raid10: remove unnecessary smp_mb() from end_sync_write NeilBrown
2012-03-14  4:40 ` [md PATCH 09/23] md/bitmap: ensure to load bitmap when creating via sysfs NeilBrown
2012-03-14  4:40 ` [md PATCH 13/23] md/raid10: handle merge_bvec_fn in member devices NeilBrown
2012-03-14  4:40 ` [md PATCH 10/23] md/raid1, raid10: avoid deadlock during resync/recovery NeilBrown
2012-03-14  4:40 ` [md PATCH 11/23] md: tidy up rdev_for_each usage NeilBrown
2012-03-14  4:40 ` [md PATCH 12/23] md: add proper merge_bvec handling to RAID0 and Linear NeilBrown
2012-03-14  4:40 ` [md PATCH 07/23] md: allow re-add to failed arrays NeilBrown
2012-03-14  4:40 ` [md PATCH 08/23] md: don't set md arrays to readonly on shutdown NeilBrown
2012-04-18 15:37   ` Alexander Lyakas
2012-04-18 17:44     ` Paweł Brodacki
2012-04-18 20:53       ` Alexander Lyakas
2012-04-18 22:48     ` NeilBrown
2012-04-19  9:11       ` Alexander Lyakas
2012-04-19  9:57         ` NeilBrown
2012-04-20 11:30           ` Paweł Brodacki
2012-04-20 12:01             ` NeilBrown
2012-04-21 15:18               ` Paweł Brodacki
2012-04-21 20:42                 ` NeilBrown [this message]
2012-04-30 10:32                   ` Paweł Brodacki
2012-04-20 16:26           ` John Robinson
2012-03-14  4:40 ` [md PATCH 14/23] md/raid1: handle merge_bvec_fn in member devices NeilBrown
2012-03-14  4:40 ` [md PATCH 22/23] md: fix clearing of the 'changed' flags for the bad blocks list NeilBrown
2012-03-14  4:40 ` [md PATCH 16/23] md/bitmap: remove some unused noise from bitmap.h NeilBrown
2012-03-14  4:40 ` [md PATCH 21/23] md/bitmap: discard CHUNK_BLOCK_SHIFT macro NeilBrown
2012-03-14  4:40 ` [md PATCH 19/23] md/bitmap: remove some pointless locking NeilBrown
2012-03-14  4:40 ` [md PATCH 20/23] md/bitmap: remove unnecessary indirection when allocating NeilBrown
2012-03-14  4:40 ` [md PATCH 17/23] md/bitmap: move printing of bitmap status to bitmap.c NeilBrown
2012-03-14  4:40 ` [md PATCH 15/23] md/raid10 - support resizing some RAID10 arrays NeilBrown
2012-03-14  6:17   ` keld
2012-03-14  6:27     ` NeilBrown
2012-03-14  7:51       ` David Brown
2012-03-14  8:32         ` NeilBrown
2012-03-14 10:20           ` David Brown
2012-03-14 12:37             ` keld
2012-03-14  4:40 ` [md PATCH 18/23] md/bitmap: change a 'goto' to a normal 'if' construct NeilBrown
2012-03-14  4:40 ` [md PATCH 23/23] md: Add judgement bb->unacked_exist in function md_ack_all_badblocks() NeilBrown

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=20120422064203.65eee938@notabene.brown \
    --to=neilb@suse.de \
    --cc=alex.bolshoy@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=pawel.brodacki@googlemail.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.