So sorry again for me regular going into hiding, but I am now back on the SMR drive problems :)
So, first, a question - how many of the changes are now in 4.3 (and unfortunately, it seems 4.3 is still not stable with these drives, still leaving only 3.18 as an full option). Next, I am trying to replicate my tests with faster data, and I get rather erratic results, e.g. (tar|buffer|tar, average file size 266MB, the source volume is capable of delivering sustained 200MB/s, so no bottleneck on the read side): summary: 2380.2 GB in 15 h 58 min 30.0 sec - average of 42.4 MB/s 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. And lastly, is there a document describing the implementation of encryption in the fs, and the goals (privacy? integrity? both?) (If there isn't, I plan to review the encryption design in f2fs myself). On Thu, Oct 08, 2015 at 05:45:11PM -0700, Jaegeuk Kim <[email protected]> wrote: > Cool and pretty much interesting topic to me! > > BTW, it might be best to publish this kind of investigation as papers or > presentation later. Maybe, I wonder how one would go about that (I never was involved with a serious paper, I will unlikely give presentations on that, but yes, I think somebody should :). On Mon, Oct 19, 2015 at 06:43:36PM +0800, Chao Yu <[email protected]> wrote: > I have tracked your IO trace log, I found an issue which may slow down our > App, so I wrote the patch to optimize the flow mainly for SMR drive. > I think we can tune up with /sys/fs/f2fs/(device)/ra_nid_pages to avoid long > latency of creating node in f2fs. Maybe that could help with my problem - a git pull of the 3.18 branch seems to have your changes in it - anything in specific that I should do? from the Changes, it doesn't quite sound as if it will be a big help, as there is very little read traffic overall, but I didn't analyze the IO trace :) it does sound like something that could be very useful for rotational disks in general, under normal conditions (reading), though. > If you want to have a test with the new tunable parameter, last git tree is > preferred. :) Sure, will be happy to do that, what should I tune how? And thanks for working on this! -- 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
