All of lore.kernel.org
 help / color / mirror / Atom feed
From: Turbo Fredriksson <turbo@bayour.com>
To: linux-raid@vger.kernel.org
Subject: Re: Which (physical) disk is broken?
Date: Mon, 27 Dec 2004 13:35:28 +0100	[thread overview]
Message-ID: <87wtv3zzov.fsf@pumba.bayour.com> (raw)
In-Reply-To: <200412241714.iBOHED921515@www.watkins-home.com> (bugzilla@watkins-home.com's message of "Fri, 24 Dec 2004 12:14:07 -0500")

>>>>> "Guy" == Guy  <bugzilla@watkins-home.com> writes:

    Guy> The info is in the superblock.  But if the disk has failed,
    Guy> you may not be able to read the superblock.

It's not THAT failed. It just have way to many bad blocks to be useful
so I took it out of service (but, unfortunately not from the machine -
I'll remember to do that next time :)...

To bad there's no 'eject' command for disks :) That would be quite funny,
shooting my colleague(s) with disks from the rack :)

    Guy> Did you say you don't use superblocks?  I guess you better
    Guy> keep a paper trail!

I do, but I always forget to update it... 

    Guy> You said: "when persistent super blocks is used (which I
    Guy> don't)."

I didn't say I don't use 'super blocks' I said 'PERSISTENT super blocks'

    Guy> But the output from mdadm said: "Persistence : Superblock is
    Guy> persistent"

He, yeah. Sorry. I saw that in the same instant it was sent, but to late
to cancel...


I've had quite a lot of time thinking about this, and I am now QUITE
sure that I created the array with 'missing' on the place where this
disk should have been.... I can VAGLEY remember that that disk kept
failing the array when I built the machine/array initially. But I'm not
sure it was THAT disk, or some other (I have a bunch of these disks
that "don't quite work")...

Thanx for all the help everyone. But seeing the thread 
'mdadm -D /dev/md3: 1  0  0  0  sync ???' on this list, leads me to
believe I'm not THAT far out in wanting some better information
on what disk is what...
-- 
Khaddafi Marxist Legion of Doom 767 747 domestic disruption Peking
subway nitrate Uzi Kennedy explosion Rule Psix NORAD Honduras
[See http://www.aclu.org/echelonwatch/index.html for more about this]

      reply	other threads:[~2004-12-27 12:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-21 11:08 Which (physical) disk is broken? Turbo Fredriksson
2004-12-22 16:39 ` Guy
2004-12-22 20:15   ` Michael
2004-12-22 23:10     ` Neil Brown
2004-12-23  0:52       ` Guy
2004-12-22 22:33   ` Turbo Fredriksson
2004-12-22 23:00     ` Neil Brown
2004-12-24 11:09       ` Turbo Fredriksson
2004-12-24 11:31         ` Theepan
2004-12-24 12:32           ` Turbo Fredriksson
2004-12-24 17:14         ` Guy
2004-12-27 12:35           ` Turbo Fredriksson [this message]

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=87wtv3zzov.fsf@pumba.bayour.com \
    --to=turbo@bayour.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 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.