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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
