[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 25 Oct 2007 23:52:08 +0200
From: Jan Kara <jack@...e.cz>
To: akpm@...ux-foundation.org
Cc: aneesh.kumar@...ux.vnet.ibm.com, cebbert@...hat.com,
davej@...emonkey.org.uk, jack@....cz, linux-ext4@...r.kernel.org,
sandeen@...hat.com
Subject: Re: + ext3-change-the-default-behaviour-on-error.patch added to -mm tree
>
> The patch titled
> ext3: change the default behaviour on error
> has been added to the -mm tree. Its filename is
> ext3-change-the-default-behaviour-on-error.patch
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
> ------------------------------------------------------
> Subject: ext3: change the default behaviour on error
> From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
>
> ext3 file system was by default ignoring errors and continuing. This is
> not a good default as continuing on error could lead to file system
> corruption. Change the default to mark the file system readonly. Debian
> and ubuntu already does this as the default in their fstab.
The change is fine as such but looking at it I just wonder
whether it would not make sence to write in /proc/mounts options
corresponding to the real state of mount options and not what we
guess user has specified... Or does anybody see a sane usecase where
userspace would rather want to see the current output? ... maybe
when user wants to inspect /proc/mounts by himself.
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> Cc: <linux-ext4@...r.kernel.org>
> Cc: Eric Sandeen <sandeen@...hat.com>
> Cc: Jan Kara <jack@....cz>
> Cc: Dave Jones <davej@...emonkey.org.uk>
> Cc: Chuck Ebbert <cebbert@...hat.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> ---
>
> fs/ext3/super.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff -puN fs/ext3/super.c~ext3-change-the-default-behaviour-on-error fs/ext3/super.c
> --- a/fs/ext3/super.c~ext3-change-the-default-behaviour-on-error
> +++ a/fs/ext3/super.c
> @@ -575,16 +575,16 @@ static int ext3_show_options(struct seq_
> le16_to_cpu(es->s_def_resgid) != EXT3_DEF_RESGID) {
> seq_printf(seq, ",resgid=%u", sbi->s_resgid);
> }
> - if (test_opt(sb, ERRORS_CONT)) {
> + if (test_opt(sb, ERRORS_RO)) {
> int def_errors = le16_to_cpu(es->s_errors);
>
> if (def_errors == EXT3_ERRORS_PANIC ||
> - def_errors == EXT3_ERRORS_RO) {
> - seq_puts(seq, ",errors=continue");
> + def_errors == EXT3_ERRORS_CONTINUE) {
> + seq_puts(seq, ",errors=remount-ro");
> }
> }
> - if (test_opt(sb, ERRORS_RO))
> - seq_puts(seq, ",errors=remount-ro");
> + if (test_opt(sb, ERRORS_CONT))
> + seq_puts(seq, ",errors=continue");
> if (test_opt(sb, ERRORS_PANIC))
> seq_puts(seq, ",errors=panic");
> if (test_opt(sb, NO_UID32))
> @@ -1559,10 +1559,10 @@ static int ext3_fill_super (struct super
>
> if (le16_to_cpu(sbi->s_es->s_errors) == EXT3_ERRORS_PANIC)
> set_opt(sbi->s_mount_opt, ERRORS_PANIC);
> - else if (le16_to_cpu(sbi->s_es->s_errors) == EXT3_ERRORS_RO)
> - set_opt(sbi->s_mount_opt, ERRORS_RO);
> - else
> + else if (le16_to_cpu(sbi->s_es->s_errors) == EXT3_ERRORS_CONTINUE)
> set_opt(sbi->s_mount_opt, ERRORS_CONT);
> + else
> + set_opt(sbi->s_mount_opt, ERRORS_RO);
>
> sbi->s_resuid = le16_to_cpu(es->s_def_resuid);
> sbi->s_resgid = le16_to_cpu(es->s_def_resgid);
> _
>
> Patches currently in -mm which might be from aneesh.kumar@...ux.vnet.ibm.com are
>
> ext2-return-after-ext2_error-in-case-of-failures.patch
> ext2-change-the-default-behaviour-on-error.patch
> ext4-return-after-ext4_error-in-case-of-failures.patch
> ext3-return-after-ext3_error-in-case-of-failures.patch
> ext3-change-the-default-behaviour-on-error.patch
> ext2-fix-the-max-file-size-for-ext2-file-system.patch
> ext3-fix-the-max-file-size-for-ext3-file-system.patch
Honza
--
Jan Kara <jack@...e.cz>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists