Messages in this thread | | | Date | Tue, 1 Sep 1998 12:12:24 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: inode with zero dtime |
| |
Hi,
On Tue, 1 Sep 1998 00:02:06 +0200, Janos Farkas <Janos.Farkas-nouce/priv-#nSPgdV0jSEF1Onu073atl/SKi/W@lk9qw.mail.eon.ml.org> said:
> But... [I can't believe this problem can't die after years.. :)] there > are cases when the inodes cannot get cleaned up before a reboot... For > example, if libc.so is upgraded, and the old one is removed. When done > correctly, no harm is done, but programs, and especially init, if linked > dynamically (and keept running), will hold on to the inode until > infinity... In this case, if you don't let the remount succeed, the > current uneducated init scripts will reboot anyway, and let fsck sort > out what happened, which is a bit rude
No. That's my whole point: this does NOT happen.
Currently, if you reboot in this situation, what happens is that the fs gets remounted readonly and the superblock gets marked cleanly unmounted. We do _not_ get an automatic fsck next time round. That's the whole problem! We simply do not have any mechanism for dealing with remounting an inconsistent filesystem readonly.
When the VFS gets the final close on an orphaned file, it calls the filesystem's delete entry point regardless of whether the fs is readonly or not. ext2fs assumes that readonly filesystems are dealt with by the VFS (which is normally true: sys_unlink() checks for EROFS itself and doesn't let the filesystem see deletes if the fs is readonly).
There is no infrastructure for dealing with this case. It is not safe to remount the fs readonly if there are orphaned inodes. The current behaviour, which is to ignore the issue completely and pretend that the filesystem is fully consistent, is about the worst possible behaviour.
> Maybe a dedicated 'hey-fsck-delete-these-inodes' special internal > (inaccessible from the filesystem) directory to keep them, and make it > easier for the kernel rather than create the possibly nonexistent > lost+found directory?
That is already part of the design for the ext2 journaling code (since in that case, the problem is even worse: we have to automatically clean up orphaned inodes even after a crash with the fs writable. After all, the whole point of journaling is to avoid the need for an fsck after a crash). The design calls for a single linked list of orphaned inodes.
--Stephen
- 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
| |