linux-ext4 - Re: [PATCH v1 0/5] ext4: Shut down block groups when damage is detected

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: <20130730015747.GA20629@thunk.org>
Date:	Mon, 29 Jul 2013 21:57:47 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Zheng Liu <gnehzuil.liu@...il.com>,
	"Darrick J. Wong" <darrick.wong@...cle.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH v1 0/5] ext4: Shut down block groups when damage is
 detected

On Mon, Jul 29, 2013 at 11:28:38AM -0400, Jeff Moyer wrote:
> I think it's important to call out the exact failure scenario you're
> trying to address.  For hard disks, if you get a read error, it can
> typically be recovered by re-writing the block.  I imagine this is what
> fsck would be doing for metadata repair.  So, I'm not at all sure why
> you'd want to track bad blocks in the file system itself.  Could you
> elaborate, please?

The basic idea why we had a similar patch in Google was so that when
we discovered a potential problem in an allocation bitmap (i.e.,
either a read error, or finding that we had freed a bloc/inode which
was already marked as freed), instead of panic'ing the entire server,
or remounting the file system read/only (or otherwise taking it
off-line), you can just avoid allocating any blocks/inodes in that
block group (since we can't trust the allocation bitmap), but we can
keep using the file system, in a somewhat degraded mode.

Of course, eventually you'd want to take the machine off-line and run
fsck on the whole thing, and then rewrite the broken allocation
bitmap.  But in the meantime, there might be circumstances where it
would be inconvenient (or violate some pesky SLA :-), to take down the
server or even the individual storage device to run fsck on it.

Regards,

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