summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChris Fries <C.Fries@motorola.com>2013-05-02 16:07:34 -0500
committerJaegeuk Kim <jaegeuk.kim@samsung.com>2013-05-08 19:54:19 +0900
commitbde582b225e98fe9e35cd67e4cb4406a6f85ae3e (patch)
tree5c6bd1d89759315d95126900c84a24a30b7f5ecf
parent531ad7d58c6476c5856653448b4c7d26427502b4 (diff)
f2fs: continue to mount after failing recovery
When unable to roll forward the journal, we shouldn't bail out and not mount, we should continue to attempt the mount. Bad recovery data is likely unrecoverable at this point, and requiring the user to try to mount again doesn't solve any issues. Signed-off-by: Chris Fries <C.Fries@motorola.com> Reviewed-by: Russell Knize <rknize2@motorola.com> Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com> Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
-rw-r--r--fs/f2fs/super.c7
1 files changed, 3 insertions, 4 deletions
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index cd0e89a1ff8..392dba26414 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -669,10 +669,9 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)
/* recover fsynced data */
if (!test_opt(sbi, DISABLE_ROLL_FORWARD)) {
err = recover_fsync_data(sbi);
- if (err) {
- f2fs_msg(sb, KERN_ERR, "Failed to recover fsync data");
- goto free_root_inode;
- }
+ if (err)
+ f2fs_msg(sb, KERN_ERR,
+ "Cannot recover all fsync data errno=%ld", err);
}
/* After POR, we can run background GC thread */