> Hi,
>
> On Tue, 25 Aug 1998 13:42:31 +0100, Delman Lee <delman@sharp.co.uk>
> said:
>
> > . Run "ldconfig" which generates a new ld.so.cache. (/etc/ld.so.cache
> > is mmapped)
>
> > . Run "mount -o remount,ro /", followed by "fsck -f /dev/hda?" shows
> > an inode with zero dtime. The inode is that of /etc/ld.so.cache before
> > ldconfig is run.
>
> That's the problem: it should be illegal to remount a fs readonly while
> there are still orphaned deleted inodes present.
>
> The problem is that closing such an inode acts as a delete. If the fs
> is readonly at the time, then either we cannot complete the delete on
> disk, or we have to fail the close. Either way lands us in a mess. The
> alternative is to prevent the fs from being marked readonly until these
> inodes finally get cleaned up.
>
> Linus, I've already sent a patch to do this. It's a genuine bug: we
> can't expect a filesystem to deal cleanly with VFS write requests after
> the VFS has already told the fs to become readonly. Patch resent below.
> This does not introduce any new failure modes; at worst, it converts the
> current behaviour (silently corrupt the fs) into a noisy one (error
> reported when we try to remount the fs readonly).
>
> --Stephen
>
I am concerned by this. Suppose I have my fs mounted with the flag to remount
ro on errors. This seems to now create a new failure mode where the fs
has errors, tries to remount ro, can't because of the orphaned deleted
inodes, and so the kernel chokes. Have I missed something here?
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html