Messages in this thread | | | Date | Tue, 1 Sep 1998 13:37:25 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: ext2fs: inode with zero dtime |
| |
Hi,
On Tue, 1 Sep 1998 08:13:59 -0400 (EDT), ssd@nevets.oau.org (Steven S. Dick) said:
> Stephen C. Tweedie <sct@redhat.com> 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.
--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
| |