lkml.org 
[lkml]   [1998]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.080 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site