[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170104234444.GD1011@jaegeuk.local>
Date: Wed, 4 Jan 2017 15:44:44 -0800
From: Jaegeuk Kim <jaegeuk@...nel.org>
To: Chao Yu <yuchao0@...wei.com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 04/10] f2fs: support IO alignment for DATA and
NODE writes
On 01/04, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2016/12/31 2:51, Jaegeuk Kim wrote:
> > This patch implements IO alignment by filling dummy blocks in DATA and NODE
> > write bios. If we can guarantee, for example, 32KB or 64KB for such the IOs,
> > we can eliminate underlying dummy page problem which FTL conducts in order to
> > close MLC or TLC partial written pages.
> >
> > Note that,
> > - it requires "-o mode=lfs".
> > - IO size should be power of 2, not exceed BIO_MAX_PAGES, 256.
> > - read IO is still 4KB.
> > - do checkpoint at fsync, if dummy NODE page was written.
>
> Which scenario we can benefit from? Any numbers?
I described it in the patch. This is not targetting for performance improvement
for now, but to address the dummy page write problem in FTL so that we can later
implement very simple host-level FTL on top of open-channel SSD.
> I doubt that there are some potential side-effect points:
> - write amplification will be more serious than before
> - free space will be more fragmented since dummy blocks is separated in whole
> address space
> - there is less chance to merge small(unaligned) IOs in block layer
I agree, so I just added this as a mount option experimentally.
One point would be that, if f2fs doesn't do this, FTL should do it. So I think,
from the system point of view, f2fs is a better layer to do it.
Thanks,
>
> Thoughts?
>
> Thanks,
Powered by blists - more mailing lists