Messages in this thread | | | Date | Fri, 06 Oct 2006 10:43:42 -0700 | From | Suzuki K P <> | Subject | Re: [RFC] PATCH to fix rescan_partitions to return errors properly - take 2 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |