| Message ID | 4BC3A071.4030501@redhat.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
Applied to the e2fsprogs maint branch. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/e2fsck/journal.c b/e2fsck/journal.c index 57783eb..4e6a7c3 100644 --- a/e2fsck/journal.c +++ b/e2fsck/journal.c @@ -214,7 +214,7 @@ static int process_journal_block(ext2_filsys fs, p = (struct process_block_struct *) priv_data; - if (blk < fs->super->s_first_data_block || + if (!blk || blk < fs->super->s_first_data_block || blk >= ext2fs_blocks_count(fs->super)) return BLOCK_ABORT;
For a filesystem that fails with: journal_bmap: journal block not found at offset 7334 on loop0 JBD: bad block at offset 7334 e2fsck won't actually fix this; it will mark the fs as clean, so it will mount, but it does not fix that block, and when the journal reaches this point again it will fail again. The following simple change to process_journal_block() might be a little drastic; it will clear & recreate the journal inode if it's sparse - i.e. if it gets block 0. I suppose we could be more complicated and try to replay the journal up to the error, but I'm not sure it's worth it since we're fscking it anyway. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html