From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] fsck.f2fs: don't allocate new blocks on unclean shutdown
Date: Mon, 5 Aug 2019 19:12:26 -0700 [thread overview]
Message-ID: <20190806021226.GC7280@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <be4ad896-31bd-a6cf-4089-9f3761305c78@huawei.com>
On 08/06, Chao Yu wrote:
> On 2019/8/6 8:47, Jaegeuk Kim wrote:
> > On 08/05, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2018/10/2 10:02, Jaegeuk Kim wrote:
> >>> + if (!is_set_ckpt_flags(cp, CP_UMOUNT_FLAG)) {
> >>> + c.alloc_failed = 1;
> >>> + return -EINVAL;
> >>> + }
> >>
> >> When I test por_fsstress case w/ quota feature enabled, I suffer below error
> >> during repair:
> >>
> >> Info: superblock features = f8 : extra_attr project_quota inode_checksum
> >> flexible_inline_xattr quota_ino
> >> Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
> >> Info: total FS sectors = 2097152 (8192 MB)
> >> Info: CKPT version = 452b7568
> >> Info: checkpoint state = 846 : quota_need_fsck crc compacted_summary
> >> orphan_inodes sudden-power-off
> >> [fsck_chk_quota_files:1784] Fixing Quota file ([ 0] ino [0x4])
> >> [ERROR] quotaio_tree.c:83:write_blk:: Cannot write block (7188): Inappropriate
> >> ioctl for device
> >> [ERROR] quotaio_tree.c:110:get_free_dqblk:: Cannot allocate new quota block (out
> >> of disk space).
> >>
> >> I found new_data_block() will reject block allocation on an unclean umounted
> >> image, result in quota file repair failure.
> >>
> >> With current implementation, I think we should mount that image again for
> >> recovery, then umount and run fsck on it again to repair quota file.
> >
> > Yes.
> >
> >>
> >> However, user didn't be noticed that how to fix this... I know there is no such
> >> report tho, I think we'd better fix this case in fsck, any thoughts? let
> >> allocation skip fsynced datas?
> >
> > Actually, that was my TODO, but I had no time to fix it, but had to stop it to
> > avoid further corruption.
>
> Copied, maybe I can help to fix it. It looks it will be easy to skip fsyned
> datas during block allocation than porting recovery flow from kernel to tools.
Cool, thanks. :)
>
> Thanks,
>
> >
> >>
> >> Thanks,
> > .
> >
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
prev parent reply other threads:[~2019-08-06 2:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 2:02 [PATCH] fsck.f2fs: don't allocate new blocks on unclean shutdown Jaegeuk Kim
2019-08-05 9:13 ` [f2fs-dev] " Chao Yu
2019-08-06 0:47 ` Jaegeuk Kim
2019-08-06 1:42 ` Chao Yu
2019-08-06 2:12 ` Jaegeuk Kim [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190806021226.GC7280@jaegeuk-macbookpro.roam.corp.google.com \
--to=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=yuchao0@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).