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

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:0.023 / U:90.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site