linux-ext4 - Re: [PATCH] ext2: Report metadata errors during fsync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <537036C8-472F-4111-8B00-7A637A00845E@sun.com>
Date:	Wed, 25 Nov 2009 16:17:32 -0700
From:	Andreas Dilger <adilger@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org, tytso@....edu,
	chris.mason@...cle.com
Subject: Re: [PATCH] ext2: Report metadata errors during fsync

On 2009-11-25, at 14:48, Andrew Morton wrote:
> On Wed, 25 Nov 2009 11:24:53 +0100
> Jan Kara <jack@...e.cz> wrote:
>> When an IO error happens while writing metadata buffers, we should
>> better report it and call ext2_error since the filesystem is probably
>> no longer consistent. Sometimes such IO errors happen while flushing
>> thread does background writeback, the buffer gets later evicted  
>> from memory, and thus the only trace of the error remains as AS_EIO  
>> bit
>> set in blockdevice's mapping. So we check this bit in ext2_fsync and
>> report the error although we cannot be really sure which buffer we
>> failed to write.
>
> So this doesn't cause significant changes in runtime behaviour unless
> the operator specified errors=remount-ro or errors=panic?


Debian, at least, always mounts filesystems with errors=remount-ro.

I _was_ thinking that this would cause errors for even regular file
data, but since it is the bdev mapping and regular files have their
own mappings any errors on the regular files should appear on a
different mapping (which is eventually returned via simple_fsync()).

The only errors returned from the bdev mapping should be metadata
errors, and we always want to call ext*_error() for those.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
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