From: Wilhelm Meier <wilhelm.meier@fh-kl.de>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm and automatic re-add / incremental mode with usb-disk
Date: Sun, 30 Nov 2008 14:52:17 +0100 [thread overview]
Message-ID: <200811301452.17352.wilhelm.meier@fh-kl.de> (raw)
In-Reply-To: <alpine.DEB.1.10.0811300808180.29266@p34.internal.lan>
Am Sonntag 30 November 2008 schrieb Justin Piszcz:
> On Sun, 30 Nov 2008, Wilhelm Meier wrote:
> > Am Sonntag 30 November 2008 schrieb Justin Piszcz:
> >> On Sun, 30 Nov 2008, Wilhelm Meier wrote:
> >
> > That might be, but what is the difference between doing the
> > re-add and re-sync on boot (that's what happens!) or if the drive
> > comes back on a running system.
>
> From the docs, when you remove and re-add it would appear to be a
> 'reocover' whereas an unclean shutdown would be resyncing (or
> repair if you do not have a bitmap).
>
> linux-2.6.27.7/Documentation/md.txt (actually a good doc to read
> btw)
>
> resync - redundancy is being recalculated after
> unclean shutdown or creation
> recover - a hot spare is being built to replace a
> failed/missing device
> repair - A full check and repair is happening. This
> is similar to 'resync', but was requested by the user, and the
> write-intent bitmap is NOT used to optimise the process.
Oh yes, I mean "recover", thats what is happening after the manual
re-add if I unplug und then replug the usb-disk.
>
> > mdadm can surely determine the state/uuid and do this - the same
> > as on reboot.
> >
> >> When you have a failed drive and you re-attach it, it will stay
> >> as a removed unit and you need to remove it and add it manually
> >> as you stated.
> >
> > the only thing I have to do is e.g.
> >
> > mdadm --re-add /dev/md1000 /dev/sdg1
> >
> > then it starts reconstructing the right way.
> >
> > So, my thought was to do this as part of a udev-rule.
> > But I think this is a common case and therefore there should be a
> > well-known solution
>
> Yeah I suppose you could do something like this. Is the purpose
> more or less to have a portable raid1 array?
Yes, exactly.
I want to have a portable usb-raid of 2 disks (or 2x2 with lvm on top)
and I want to plug and unplug the disks freely.
--
Wilhelm
next prev parent reply other threads:[~2008-11-30 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-30 11:31 mdadm and automatic re-add / incremental mode with usb-disk Wilhelm Meier
2008-11-30 11:48 ` Justin Piszcz
2008-11-30 13:03 ` Wilhelm Meier
2008-11-30 13:10 ` Justin Piszcz
2008-11-30 13:52 ` Wilhelm Meier [this message]
2008-12-01 15:21 ` Mario 'BitKoenig' Holbe
2008-12-01 0:32 ` NeilBrown
2008-12-01 6:46 ` Wilhelm Meier
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=200811301452.17352.wilhelm.meier@fh-kl.de \
--to=wilhelm.meier@fh-kl.de \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-raid@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).