From: Chao Yu <chao2.yu@samsung.com>
To: 'Jaegeuk Kim' <jaegeuk@kernel.org>
Cc: 'Marc Lehmann' <schmorp@schmorp.de>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 3/5] f2fs: report readonly status in ->fsync
Date: Wed, 30 Dec 2015 14:46:03 +0800 [thread overview]
Message-ID: <00e201d142cd$d75c14c0$86143e40$@samsung.com> (raw)
In-Reply-To: <20151230003246.GB13809@jaegeuk.local>
Hi Jaegeuk,
> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Wednesday, December 30, 2015 8:33 AM
> To: Chao Yu
> Cc: 'Marc Lehmann'; linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 3/5] f2fs: report readonly status in ->fsync
>
> Hi Chao,
>
> ...
>
> > > > And one more thing is how do you think of moving inline dot recovery into
> > > > fsck?
> > >
> > > Hmm, we can't move that part entirely into fsck regarding to backward
> > > compatibility.
> >
> > IMO, dynamical repair could be optional, not a must. Because when touching
> > such incomplete directory in ->lookup, we could leave some dmesg to remind
> > user to repair. Or if user found this issue by himself, also he could
> > repair it by using fsck. So this shouldn't case a backward compatibility
> > issue, or am I missing something?
>
> Hmm, it seems that maybe I misunderstood your *moving it into fsck*.
What I mean is 1) enable repair ability in fsck, 2) keep repair in kernel
side optionally. For compatibility, we leave dmesg for user when touch this
kind of dir if we choose to disable repair in kernel.
> Anyway, I'm fine to add kernel messages as well.
OK, will do it in ("f2fs: fix to stop recovering dot dentries in a readonly fs")
> And, in any case, the only way to fix this case is to run fsck at first.
> One approach, as I implemented, is to set a flag and then repair it at runtime.
>
> The other one is to repair by fsck, as you suggested.
> In this case, my concern is that current fsck is working without allocating
> blocks, since it is a little bit risky right now.
> For example, if there is no valid user block, not free space, fsck should handle
> ENOSPC while changing the existing disk, which has not been fully validated so
> far.
That' right.
>
> Ah, otherwise, we can activate inline_dentry by fsck for this special case, once
> inline_dentry in f2fs becomes pretty much stable later. :)
Or we can active inline_data for file which has i_size less than MAX_INLINE_SIZE.
That will be cool to use inline_dentry by default! :)
Thanks,
>
> Thanks,
>
> >
> > > We can add that in fsck, but it needs another block
> > > allocation part which we need to handle -ENOSPC in fsck as well.
> >
> > That's right, is it possible to do defragment (gc) if there is no
> > more space when allocating block?
> >
> > Thanks,
> >
> > >
> > > Thanks,
> > >
> > > >
> > > > Thanks,
> > > >
> > > > >
> > > > > I only looked at the diff, so if I missed the context and my reasoning
> > > > > doesn't apply, forgive and ignore me :)
> > > > >
> > > > > --
> > > > > The choice of a Deliantra, the free code+content MORPG
> > > > > -----==- _GNU_ http://www.deliantra.net
> > > > > ----==-- _ generation
> > > > > ---==---(_)__ __ ____ __ Marc Lehmann
> > > > > --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
> > > > > -=====/_/_//_/\_,_/ /_/\_\
------------------------------------------------------------------------------
prev parent reply other threads:[~2015-12-30 6:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-24 10:07 [PATCH 3/5] f2fs: report readonly status in ->fsync Chao Yu
2015-12-26 6:32 ` Marc Lehmann
2015-12-28 9:59 ` Chao Yu
2015-12-28 22:43 ` Jaegeuk Kim
2015-12-29 6:21 ` Chao Yu
2015-12-30 0:32 ` Jaegeuk Kim
2015-12-30 6:46 ` Chao Yu [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='00e201d142cd$d75c14c0$86143e40$@samsung.com' \
--to=chao2.yu@samsung.com \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=schmorp@schmorp.de \
/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).