From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: vol_id and RAID1 members
Date: Fri, 27 Jan 2006 16:48:16 +0000 [thread overview]
Message-ID: <20060127164816.GA5332@vrfy.org> (raw)
In-Reply-To: <20060124223036.GA16374@wonderland.linux.it>
On Fri, Jan 27, 2006 at 05:35:46PM +0100, Marco d'Itri wrote:
> On Jan 27, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> > > Yes. Indeed, vol_id gets EIO when trying to read the superblock.
> > >
> > > I think that in this case it should report the error and exit, because
> > > as I showed if the partition really is an array member then it will
> > > report wrong information which if used will cause data loss.
> >
> > But how can returning an error by reading the very end of the device
> > be an indication for a raid device? If we can't find a raid signature,
> What I meant is that failure to read the partition should be an
> indication for broken devices.
The "failure to read the partition" you mean is not to be able to
read the last few sectors? Yeah, it's some kind of broken, but it
happens and it is perfectly useable.
> > we should look for a filesystem. I've seen some devices, where the
> > reported size is not fully readable and they would fail with such a logic,
> > which would break other things.
> These devices looks broken or at best misconfigured.
> In which sane and normal scenario would a partition have sectors which
> return EIO when read, but be otherwise fully functional?
Oh, that's hardware magic and some devices just don't report the right
size and you need to do a binary search to determine the _real_ size.
We just can't ignore devices which report an incorrect size or depend on
the reported size to be completely correct in all cases.
The real failure to look for, is why your raid member has no longer a
signature at all, right?
Kay
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2006-01-27 16:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-24 22:30 vol_id and RAID1 members Marco d'Itri
2006-01-24 23:55 ` Kay Sievers
2006-01-27 13:06 ` Marco d'Itri
2006-01-27 16:02 ` Kay Sievers
2006-01-27 16:35 ` Marco d'Itri
2006-01-27 16:48 ` Kay Sievers [this message]
2006-01-27 16:56 ` Marco d'Itri
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=20060127164816.GA5332@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@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).