From: Suzuki K P <suzuki@in.ibm.com>
To: Erik Mouw <erik@harddisk-recovery.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
andmike@us.ibm.com
Subject: Re: [RFC] PATCH to fix rescan_partitions to return errors properly - take 2
Date: Fri, 06 Oct 2006 10:43:42 -0700 [thread overview]
Message-ID: <452695CE.8080901@in.ibm.com> (raw)
In-Reply-To: <20061006125336.GA27183@harddisk-recovery.nl>
Erik Mouw wrote:
> On Thu, Oct 05, 2006 at 01:32:34PM -0700, Suzuki Kp wrote:
>
>>Btw, do you think it is a good idea to let the other partition checkers
>>run, even if one of them has failed ?
>
>
> Yes, just let them run. Partition information doesn't need to be on the
> very first sector of the drive. If the first sector is bad and the
> partition table for your funky XYZ partition table format lives on the
> tenth sector, then a checker that checks the first sector would fail
> and prevent your checker from running.
>
> OTOH: having ten partition checkers check the same bad first sector
> doesn't really speed up the partion check process (for that reason we
> disable partition checking for drives we get for recovery). A way to
> solve that would be to keep a list of bad sectors: if the first checker
> finds a bad sector, it notes it down in the list so the next checker
> wouldn't have to try to read that particular sector. Maybe that's too
> much work to do in kernel and we'd better move the partition checking
> to userland.
>
>
>>Right now, the check_partition runs the partition checkers in a
>>sequential manner, until it finds a success or an error.
>
>
> I think it's best not to change the current behaviour and let all
> partition checkers run, even if one of them failed due to device
> errors. I wouldn't mind if the behaviour changed like you propose,
> though.
>
At present, the partition checkers doesn't run, if one of the preceeding
checker has reported an error ! *But*, some of the checkers doesn't
report the I/O error which they came across! So, this may let others
run. Thats not we want, right. We would like them to return I/O errors,
and and the check_partition should let other partition checkers continue.
Comments ?
Thanks,
Suzuki
>
> Erik
>
next prev parent reply other threads:[~2006-10-06 17:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 1:00 [RFC] PATCH to fix rescan_partitions to return errors properly Suzuki Kp
2006-10-04 13:09 ` Erik Mouw
2006-10-04 16:50 ` Suzuki Kp
2006-10-04 17:08 ` Erik Mouw
2006-10-04 17:37 ` Suzuki Kp
2006-10-05 10:40 ` Erik Mouw
2006-10-05 20:32 ` [RFC] PATCH to fix rescan_partitions to return errors properly - take 2 Suzuki Kp
2006-10-05 22:07 ` Andrew Morton
2006-10-06 12:53 ` Erik Mouw
2006-10-06 17:43 ` Suzuki K P [this message]
2006-10-06 21:07 ` Erik Mouw
2006-10-07 1:46 ` [RFC] Fix check_partition routines ( was Re: [RFC] PATCH to fix rescan_partitions to return errors properly - take 2) Suzuki K P
2006-10-07 2:45 ` Andrew Morton
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=452695CE.8080901@in.ibm.com \
--to=suzuki@in.ibm.com \
--cc=akpm@osdl.org \
--cc=andmike@us.ibm.com \
--cc=erik@harddisk-recovery.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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.