linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "Lukáš Czerner" <lczerner@redhat.com>,
	"Nikola Ciprich" <nikola.ciprich@linuxbox.cz>,
	linux-ext4@vger.kernel.org
Subject: Re: info about filesystem errors in /sys/fs/ext4/... ?
Date: Mon, 5 May 2014 15:15:57 -0400	[thread overview]
Message-ID: <20140505191557.GM22287@thunk.org> (raw)
In-Reply-To: <5367A5E5.10809@redhat.com>

For the record, since this was discussed on the ext4 weekly
teleconference...

The reason why I've been hesitant about allowing any file system to be
checked by e2fsck while being mounted read-only is because of the
following failure scenario:

1) The kernel discovers that a file system has been corrupted, so it
marks the file system as being inconsistent and it remounts the file
system read-only.

2) The user runs e2fsck on the file system, while it is still mounted
read-only, and fixes it.

3) The kernel still has cached data structures with incorrect inode
reference counts, etc.  So when the user then remounts the file system
read/write, the file system gets corrupted again, and the user suffers
data loss.


This could happen with the root file system as well, of course, but
there is a big, large, scary message making it clear that you *MUST*
reboot after repairing a corrupted root file system.  The real issue
is encouraging users from checking mounted file systems at all.  One
approach would be do to require a command-line option of the form
--i-know-this-is-dangerous-and-I-could-lose-data, or some such.
Apparently xfs does something like this, with a xfs_repair -d ('D' is
for Dangerous).

Another approach which Andreas Dilger suggested, and which we will
likely use, is one where we snapshot the last fsck time from the
superblock when the file system is mounted or remounted read-only.
Then when the user tries to remount the file system read-write, if the
last fsck time has been changed, we reject the r/w remount request.

Regards,

						- Ted

      reply	other threads:[~2014-05-05 19:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05  7:08 info about filesystem errors in /sys/fs/ext4/... ? Nikola Ciprich
2014-05-05 11:03 ` Lukáš Czerner
2014-05-05 11:14   ` Nikola Ciprich
2014-05-05 11:59   ` Theodore Ts'o
2014-05-05 14:53     ` Eric Sandeen
2014-05-05 19:15       ` Theodore Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140505191557.GM22287@thunk.org \
    --to=tytso@mit.edu \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=nikola.ciprich@linuxbox.cz \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).