[lkml]   [1998]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ext2fs: inode with zero dtime

On Tue, 1 Sep 1998 08:13:59 -0400 (EDT), (Steven
S. Dick) said:

> Stephen C. Tweedie <> wrote:
>> That's the problem: it should be illegal to remount a fs readonly while
>> there are still orphaned deleted inodes present.

> Nooooo! That defeats the major purpose of remounting read only...

> Remounting read only should not fail under this condition.

The may_remount_ro check SHOULD still return false under this condition.
Error-triggered remount-ro does not go through that sanity check, so
it's not a problem.

> Remounting read only is done when?
> 1) when the filesystem detects something critical wrong
> 2) when the system is about to shut down
> 3) when done by hand

> For case 1, it MUST succeed, or risk panicing the system totally.
> Most likely, we want to remount read only, but leave it marked dirty.

That's an entirely separate issue. Currently an error can mark the fs
readonly even if there are still files open for write. Are you
complaining about that too? Dealing with error conditions is not the
issue here: on error we just want to freeze the fs regardless of the
current conditions. We do that anyway.

The issue is whether a user-requested remount can succeed with orphaned
files. As long as the filesystem is entirely unable to cleanly deal
with that situation, such a remount must be rejected.

> For case 2, would it be reasonable to close the open files before the
> remount, and allow them to be actually deleted before the remount
> completes? Perhaps they could be deleted on disk, but left undeleted
> as far as the in memory copy is concerned--we're about to reboot
> anyway, right?

Yes. In principle this would be ideal. The problem, of course, is that
the current user-space tools do not differentiate between remount for
shutdown and remount for any other reason. As such, right now the only
case we have got to deal with is the general purpose case.

> For case 3, we can't guess what the user wants. If files are deleted,
> as in case 2, then the filesystem should not be allowed to be
> remounted RW.

It is even _more_ inconsistent to say that with orphaned files, we'll
let the user remount ro but not rw again!

The only failsafe solution which would allow orphaned files to be dealt
with is to modify the filesystems to explicitly recognise orphaned files
and deal with them in some manner. Right now, the filesystems do not do
this. Right now, the VFS deals with this by ignoring the issue and
silently corrupting filesystems without marking them unclean. Right
now, allowing readonly remount with orphaned files is completely broken:
disallowing such a remount will at least convert the failure into
something e2fsck can detect and correct on reboot.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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