Re: blog article about f2fs on smr drives

[Chao Yu <chao2.yu@samsung.com>]

Hi Marc,

> -----Original Message-----
> From: Marc Lehmann [mailto:schmorp@schmorp.de]
> Sent: Tuesday, November 17, 2015 7:53 AM
> To: Chao Yu
> Cc: linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] blog article about f2fs on smr drives
> 
> On Mon, Nov 16, 2015 at 12:31:06PM +0800, Chao Yu <chao2.yu@samsung.com> wrote:
> > I think you could get the change information in below link:
> >
> > http://sourceforge.net/p/linux-f2fs/mailman/message/34427519/
> 
> Right, I saw the merge requests, but I don't know if these have been accepted
> for 4.3. I assume they are, thanks for finding them again for me.
> 
> > > While there are stretches at >>100MB/s, most of the time, this is at less,
> > > and often for long stretches at ~10MB/s, which is the reason the end
> > > result is (relatively) bad.
> >
> > Could you please share us IO trace log?
> 
> I am already working on it, I just didn't expect it to be a problem. Also,
> I did it without your patch.
> 
> > > And lastly, is there a document describing the implementation of
> > > encryption in the fs, and the goals (privacy? integrity? both?)
> >
> > The feature was ported from ext4, please refer following article:
> >
> > https://lwn.net/Articles/639427/
> 
> I see, so it inherits all the security issues of that design.
> 
> > Actually, as I test in flash device, it does help to improve performance in
> > workload of creating nodes aggressively, this is because we add asynchronous
> > readahead to mitigate small synchronous random read which may block all APPs
> > sometime. Considering rotational device has worse random synchronous read
> > performance, I expect better result in SMR.
> 
> Ok, that could help, as even a relatively small number of random reads could
> cause performance regressions (did the original 3.18 code not yet do this?)

As Jaegeuk mentioned, the serious problem here is all node allocaters who may
generate more dirty data later will be blocked by it, so continuous write
stream will be broken, IOs in disk may drop after a while.

> 
> I was a bit confused by the use of SMR, as SMRs don't suffer more from
> random reads as othere rotational devices (in fact, they can suffer less,
> if the data is still in the journal).

You mean journal region in disk, right? Read IO still goes to that region on
disk. So why SMR suffers less than other rotations? Or readahead in that region
can do some help when most of random reads goes to the journal.

> 
> > > Sure, will be happy to do that, what should I tune how? And thanks for
> > > working on this!
> >
> > IMO, one way is to do the test with default value and then do geometrically
> > increasing with the value to see how it affects the IO.
> 
> I am not sure I can make a large number of tests, I will try to do smaller
> tests and see if I can make more of them and see a difference.

That's OK, one thing I should mention is that small file is preferred in our
test. :)

Thanks,

> 
> Thanks again!
> 
> --
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\


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