From: Vasily Averin <vvs@sw.ru>
To: Theodore Tso <tytso@mit.edu>, Stephen Tweedie <sct@redhat.com>,
Andrew Morton <akpm@osdl.org>,
adilger@clusterfs.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-ext4@vger.kernel.org, devel@openvz.org, cmm@us.ibm.com
Cc: Eric Sandeen <sandeen@sandeen.net>, Kirill Korotaev <dev@openvz.org>
Subject: ext2/ext3 errors behaviour fixes
Date: Wed, 04 Oct 2006 11:50:00 +0400 [thread overview]
Message-ID: <452367A8.3010405@sw.ru> (raw)
Hello all,
Current error behaviour for ext2 and ext3 filesystems does not fully correspond
to the documentation and should be fixed.
According to man 8 mount, ext2 and ext3 file systems allow to set one of 3
different on-errors behaviours:
---- start of quote man 8 mount ----
errors=continue / errors=remount-ro / errors=panic
Define the behaviour when an error is encountered. (Either ignore errors and
just mark the file system erroneous and continue, or remount the file system
read-only, or panic and halt the system.) The default is set in the filesystem
superblock, and can be changed using tune2fs(8).
---- end of quote ----
However EXT3_ERRORS_CONTINUE is not read from the superblock, and thus
ERRORS_CONT is not saved on the sbi->s_mount_opt. It leads to the incorrect
handle of errors on ext3.
Then we've checked corresponding code in ext2 and discovered that it is
buggy as well:
- EXT2_ERRORS_CONTINUE is not read from the superblock (the same);
- parse_option() does not clean the alternative values and thus
something like (ERRORS_CONT|ERRORS_RO) can be set;
- if options are omitted, parse_option() does not set any of these options.
Therefore it is possible to set any combination of these options on the ext2:
- none of them may be set:
EXT2_ERRORS_CONTINUE on superblock / empty mount options;
- any of them may be set using mount options;
- 2 any options may be set: by using EXT2_ERRORS_RO/EXT2_ERRORS_PANIC on the
superblock and other value in mount options;
- and finally all three options may be set by adding third option in remount.
Currently ext2 uses these values only in ext2_error() and it is not leading to
any noticeable troubles. However somebody may be discouraged when he will try to
workaround EXT2_ERRORS_PANIC on the superblock by using errors=continue in mount
options.
The following patches fix this.
Thank you,
Vasily Averin
SWsoft Virtuozzo/OpenVZ Linux kernel team
next reply other threads:[~2006-10-04 7:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 7:50 Vasily Averin [this message]
2006-10-04 15:02 ` ext2/ext3 errors behaviour fixes Andreas Dilger
2006-10-04 15:07 ` Andreas Dilger
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=452367A8.3010405@sw.ru \
--to=vvs@sw.ru \
--cc=adilger@clusterfs.com \
--cc=akpm@osdl.org \
--cc=cmm@us.ibm.com \
--cc=dev@openvz.org \
--cc=devel@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@sandeen.net \
--cc=sct@redhat.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.