Hi Marc, > -----Original Message----- > From: Marc Lehmann [mailto:[email protected]] > Sent: Tuesday, November 17, 2015 7:53 AM > To: Chao Yu > Cc: [email protected] > Subject: Re: [f2fs-dev] blog article about f2fs on smr drives > > On Mon, Nov 16, 2015 at 12:31:06PM +0800, Chao Yu <[email protected]> > 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 > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\ ------------------------------------------------------------------------------ _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
