>From: Ted Ts'o <ty...@mit.edu> > Not really. E2fsck checks to see if it is on battery, and if so, it > will let the system go a few extra mounts before really forcing a > check. It works fine for laptops that are sometimes started while on > battery.
#326647 needs an argument for `fsck` that is passed to the back-ends that inhibits precautionary checks. A script is better suited for checking whether the system is on battery (it could be on a UPS battery instead of an internal battery)... > The difference between this and what you wanted in Bug #575343 is that > what you want requires coordination between fsck and e2fsck. That's a > huge amount of complexity, which IMHO isn't warranted and isn't Two options, perhaps "--retrieve-forced-check-status" and "--disable-preemptive-checks", then some logic to use those is that much complexity? > needed. With staggered mount counts (already implemented), the > problem is largely solved, at a fraction of the complexity which you > are requesting. As mentioned before on this very same bug report, I'd hardly call the problem "largely solved". Perhaps "partially solved for one common usage case", but hardly "largely". Any system that doesn't reboot that often (say, a server on reasonably reliable hardware without huge amounts of activity) will tend to always trigger the date-based checks. Since doing any check resets the last checked time, those will coalesce and you'll end up checking everything at once all the time. > The real right answer is to run the e2fsck in an initial ramdisk, and > only mount the root filesystem after it has been checked. That's a > distro-level question, and again, it's a huge amount of complexity > that no one has been really interested in implementing. In the rare > cases that it is necessary, the solution is to tell the user to use a > rescue CD. Does indeed strike me as a distro-level question. OTOH I'd hardly rate copying an extra 3-10 files to an initrd image, plus a tiny bit of scripting as a huge amount of complexity. > If you would like to implement the better solution, you can do the > time-honored thing in the open source world --- send a patch. Or pay > someone to do it for you. Alas, right now I'm having to fight other, far less avoidable wars. :-( This could happen, but isn't yet in the cards. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | e...@gremlin.m5p.com PGP F6B23DE0 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
