On Thu, May 27, 2010 at 05:58:12PM -0700, Elliott Mitchell wrote:
>
> Oy vey! I'm inclined to suggest that if this really does happen, that
> sounds like a bug... I could understand funky occurances if after
> reloading, the kernel can no longer find the FS data structures (device
> was erased), but I would expect the FS data structures to be otherwise
> invalidated. I understand the situation and reasoning with `dump` causing
> problems, but the mount/remount/unmount really should be flushing
> everything.
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.
Every once in a while, I'll get someone annoying, usually a old
Multics hand, which will say something like --- in my day, Multics
could do the equivalent of fsck and repair a file system while it was
mounted, even while it was being modified at the time. At which point
I just smile sweetly and say, "It's Open Source. If you're so smart,
you do it yourself, and send me the patches. If they're maintainable,
I'm sure someone will merge them in."
Someone who is reasonable will say, well, the chances that we need to
fix the root file system (especially if we're responsible and keep the
root file system small, so it doesn't need to be modified much during
normal system operation), will mean that it is extremely rare that the
root file system will be damanged and will require special treatment.
So maybe this isn't a good use of our time.
But hey, if this is important to you, *please* feel free and implement
it, and show us how smart you are.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
