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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
