All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery
Date: Thu, 29 Sep 2016 17:53:00 -0700	[thread overview]
Message-ID: <20160930005300.GC44999@jaegeuk> (raw)
In-Reply-To: <5b3d81fe-902e-5512-4766-30ad62390373@huawei.com>

On Thu, Sep 29, 2016 at 08:01:32PM +0800, Chao Yu wrote:
> On 2016/9/20 10:55, Jaegeuk Kim wrote:
> > Previously, we used cp_version only to detect recoverable dnodes.
> > In order to avoid same garbage cp_version, we needed to truncate the next
> > dnode during checkpoint, resulting in additional discard or data write.
> > If we can distinguish this by using crc in addition to cp_version, we can
> > remove this overhead.
> > 
> > There is backward compatibility concern where it changes node_footer layout.
> > But, it only affects the direct nodes written after the last checkpoint.
> > We simply expect that user would change kernel versions back and forth after
> > stable checkpoint.
> 
> Seems with new released v4.8 f2fs, old image with recoverable data could be
> mounted successfully, but meanwhile all fsynced data which needs to be recovered
> will be lost w/o any hints?
> 
> Could we release a new version mkfs paired with new kernel module, so we can tag
> image as a new layout one, then new kernel module can recognize the image layout
> and adjust version suited comparing method with old or new image?

Hmm, how about adding a checkpoint flag like CP_CRC_RECOVERY_FLAG?
Then, we can proceed crc|cp_ver, if the last checkpoint has this flag.

Any thought?

> 
> Thanks,
> 
> 

------------------------------------------------------------------------------

WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery
Date: Thu, 29 Sep 2016 17:53:00 -0700	[thread overview]
Message-ID: <20160930005300.GC44999@jaegeuk> (raw)
In-Reply-To: <5b3d81fe-902e-5512-4766-30ad62390373@huawei.com>

On Thu, Sep 29, 2016 at 08:01:32PM +0800, Chao Yu wrote:
> On 2016/9/20 10:55, Jaegeuk Kim wrote:
> > Previously, we used cp_version only to detect recoverable dnodes.
> > In order to avoid same garbage cp_version, we needed to truncate the next
> > dnode during checkpoint, resulting in additional discard or data write.
> > If we can distinguish this by using crc in addition to cp_version, we can
> > remove this overhead.
> > 
> > There is backward compatibility concern where it changes node_footer layout.
> > But, it only affects the direct nodes written after the last checkpoint.
> > We simply expect that user would change kernel versions back and forth after
> > stable checkpoint.
> 
> Seems with new released v4.8 f2fs, old image with recoverable data could be
> mounted successfully, but meanwhile all fsynced data which needs to be recovered
> will be lost w/o any hints?
> 
> Could we release a new version mkfs paired with new kernel module, so we can tag
> image as a new layout one, then new kernel module can recognize the image layout
> and adjust version suited comparing method with old or new image?

Hmm, how about adding a checkpoint flag like CP_CRC_RECOVERY_FLAG?
Then, we can proceed crc|cp_ver, if the last checkpoint has this flag.

Any thought?

> 
> Thanks,
> 
> 

  reply	other threads:[~2016-09-30  0:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20  2:55 [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery Jaegeuk Kim
2016-09-20  2:55 ` [PATCH 2/2] f2fs: put directory inodes before checkpoint in " Jaegeuk Kim
2016-09-20  2:55   ` Jaegeuk Kim
2016-09-20 15:48 ` [f2fs-dev] [PATCH 1/2] f2fs: use crc and cp version to determine " Chao Yu
2016-09-21  0:45   ` Jaegeuk Kim
2016-09-24  6:00     ` Chao Yu
2016-09-24  6:00       ` [f2fs-dev] " Chao Yu
2016-09-24 18:20       ` Jaegeuk Kim
2016-09-29 12:01 ` Chao Yu
2016-09-29 12:01   ` Chao Yu
2016-09-30  0:53   ` Jaegeuk Kim [this message]
2016-09-30  0:53     ` Jaegeuk Kim
2016-09-30  1:04     ` Chao Yu
2016-09-30  1:04       ` Chao Yu
2016-09-30 17:10 ` [PATCH 1/2 v2] " Jaegeuk Kim
2016-10-01  0:26   ` Chao Yu
2016-10-01  0:26     ` [f2fs-dev] " Chao Yu
2016-10-01  0:54     ` Jaegeuk Kim
2016-10-01  0:54       ` [f2fs-dev] " Jaegeuk Kim

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=20160930005300.GC44999@jaegeuk \
    --to=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.