linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Phil Turmel <philip@turmel.org>
Cc: Wols Lists <antlists@youngman.org.uk>,
	Eric Mei <meijia@gmail.com>,
	linux-raid@vger.kernel.org
Subject: Re: Last working drive in RAID1
Date: Fri, 6 Mar 2015 08:52:22 +1100	[thread overview]
Message-ID: <20150306085222.19dd30ce@notabene.brown> (raw)
In-Reply-To: <54F8B5D2.8070304@turmel.org>

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

On Thu, 05 Mar 2015 15:00:18 -0500 Phil Turmel <philip@turmel.org> wrote:

> On 03/05/2015 10:55 AM, Wols Lists wrote:
> > Sorry to butt in, but I'm finding this conversation a bit surreal ...
> > take everything I say with a pinch of salt. But the really weird bit
> > was "what does linux do if /dev/sda disappears?"
> > 
> > In the old days, with /dev/hd*, the * had a hard mapping to the
> > hardware. hda was the ide0 primary, hdd was the ide1 secondary, etc
> > etc. I think I ran several systems with just hdb and hdd. Not a good
> > idea, but.
> > 
> > Nowadays, with sd*, the letter is assigned in order of finding the
> > drive. So if sda is removed, linux moves all the other drives and what
> > was sdb becomes sda.
> 
> On reboot, yes.  Not live.  If /dev/sda has anything using it when
> unplugged, it stays there and gives errors.  Existing devices retain
> their names, and new devices are added to the end.  Only if all users
> are completely unhooked will a kernel name get re-used live.
> 
> > Which is why you're advised now to always refer
> > to drives by their BLKDEV or whatever, as linux provides no guarantees
> > whatsoever about sd*. The blockdev may only be a symlink to whatever
> > the sd*n code of the disk is, but it makes sure you get the disk you
> > want when the sd*n changes under you.
> 
> Correct, but once assembled or mounted, the kernel names are locked.
> 
> > Equally surreal is the comment about "what does raid1 do with no
> > working devices?". Surely it will do nothing, if there's no spinning
> > rust or whatever underneath it? You can't corrupt it if there's
> > nothing there to corrupt?
> 
> It has to stay there to give errors to the upper layers that are still
> hooked to it.  When they are administratively "unhooked", aka unmounted
> or disassociated with mdadm --remove.
> 
> Or, quite possibly, the device is plugged back in, at which point the
> device name is there for it (as long as you use the same port, of
> course).  In which case the filesystem may very well resume successfully.

I was with you right up to this last point.
When a device is unplugged and then plugged back in, it will always get a new
name.  Detecting "is the same device" is far from fool-proof, particularly as
the device could have been plugged into some other machine and has 'fsck' etc
run.
Once a mounted device is unplugged, that mount is permanently unusable.

NeilBrown


> 
> > Sorry again if this is inappropriate, but you're coming over as so
> > buried in the trees that you can't see the wood.
> 
> Sometimes the expanded view is appropriate :-)
> 
> Regards,
> 
> Phil Turmel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  reply	other threads:[~2015-03-05 21:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 19:55 Last working drive in RAID1 Eric Mei
2015-03-04 21:46 ` NeilBrown
2015-03-04 22:48   ` Eric Mei
2015-03-04 23:26     ` NeilBrown
2015-03-05 15:55       ` Wols Lists
2015-03-05 19:54         ` Eric Mei
2015-03-05 20:00         ` Phil Turmel
2015-03-05 21:52           ` NeilBrown [this message]
2015-03-06  9:21             ` Chris
2015-03-05 21:54           ` Chris
2015-03-05 20:23       ` Eric Mei

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=20150306085222.19dd30ce@notabene.brown \
    --to=neilb@suse.de \
    --cc=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=meijia@gmail.com \
    --cc=philip@turmel.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).