linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <chao2.yu@samsung.com>
To: 'Jaegeuk Kim' <jaegeuk@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: refactor flush_nat_entries codes for reducing NAT writes
Date: Tue, 17 Jun 2014 10:33:12 +0800	[thread overview]
Message-ID: <002301cf89d4$97aaf7f0$c700e7d0$@samsung.com> (raw)
In-Reply-To: <001201cf87c6$92b9fad0$b82df070$@samsung.com>

Hi all,

There are problem in this patch, please ignore this patch, sorry for the noise.
I will resend later.

> -----Original Message-----
> From: Chao Yu [mailto:chao2.yu@samsung.com]
> Sent: Saturday, June 14, 2014 7:48 PM
> To: Jaegeuk Kim
> Cc: linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-devel@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH] f2fs: refactor flush_nat_entries codes for reducing NAT writes
> 
> Although building NAT journal in cursum reduce the read/write work for NAT
> block, but previous design leave us lower performance when write checkpoint
> frequently for these cases:
> 1. if journal in cursum has already full, it's a bit of waste that we flush all
>    nat entries to page for persistence, but not to cache any entries.
> 2. if journal in cursum is not full, we fill nat entries to journal util
>    journal is full, then flush the left dirty entries to disk without merge
>    journaled entries, so these journaled entries may be flushed to disk at next
>    checkpoint but lost chance to flushed last time.
> 
> In this patch we merge dirty entries located in same NAT block to nat entry set,
> and linked all set to list, sorted ascending order by entries' count of set.
> Later we flush entries in sparse set into journal as many as we can, and then
> flush merged entries to disk.
> 



------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

      reply	other threads:[~2014-06-17  2:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-14 11:47 [PATCH] f2fs: refactor flush_nat_entries codes for reducing NAT writes Chao Yu
2014-06-17  2:33 ` 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='002301cf89d4$97aaf7f0$c700e7d0$@samsung.com' \
    --to=chao2.yu@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).