I spotted bugs #326647 and #526398 while doing a bit of research for another problem. #326647 is worth mentioning because it requires almost exactly the same key ingredient as #575343. Mainly some method to inhibit precautionary checks while allowing regular unclean-FS checks to go through (anything else triggers #526398).
#575343 also needs a common method to query precautionary check status, in order to determine which filesystem to run the precautionary check on (otherwise if you simply choose the first filesystem on disk, the others will starve). >From: ty...@mit.edu > A mount/unmount will flush everything. A remount *can't* possibly > flush everything. If an inode is actively in use (i.e. /bin/bash, > /sbin/e2fsck, /sbin/init, etc.), it can't be flushed; it's in use, > which means its pinned in memory. Could you make try to figure out a > way to gently update any modified elements of the in-core inode? > Sure, anything is possible. But it would be really tricky to get > right, and for the last four decades, all Unix systems and Linux > systems have dealt with this case by a forced reboot of system if fsck > needs to fix something in the root file system. Since I haven't been working with Linux kernel internals recently, I don't know the best solution. From the outside view from userspace, there are two behaviors that come to mind as perfectly acceptable, hopefully one or the other might be easy to implement: Option #1> When mount() is called, check consistency between things pinned in memory (from programs executing in memory) and on-disk data (generated by e2fsck). If they're different, return EBUSY, similar to how remounting read-only or unmounting will fail if a file is open for writing or a deleted file is still open. Option #2> Copying from SunOS^WSolaris, why bother with gentle? If fsck updates something relating having to do with a file being read/executed during boot, you're pretty will screwed anyway (gee, if /lib/libc.so is corrupt, how can one expect `e2fsck` to produce correct results anyway?). If `fsck` updates a block being executed by a program, just let the program immediately start executing the new block, sure it will almost certainly explode, but at least nothing is any more corrupt than it already was. -- (\___(\___(\______ --=> 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
