Hi Alexander, On Fri, Aug 19, 2016 at 02:56:12PM +0300, Alexander Gordeev wrote: > Hi Jaegeuk, > > 19.08.2016, 05:41, "Jaegeuk Kim" <[email protected]>: > > Hello, > > > > On Thu, Aug 18, 2016 at 02:04:55PM +0300, Alexander Gordeev wrote: > > > > ... > > > >> >>>>>>> Here is also /sys/kernel/debug/f2fs/status for reference: > >> >>>>>>> =====[ partition info(sda). #0 ]===== > >> >>>>>>> [SB: 1] [CP: 2] [SIT: 4] [NAT: 118] [SSA: 60] [MAIN: > >> 29646(OverProv:1529 > >> >>>>>>> Resv:50)] > >> >>>>>>> > >> >>>>>>> Utilization: 94% (13597314 valid blocks) > >> >>>>>>> - Node: 16395 (Inode: 2913, Other: 13482) > >> >>>>>>> - Data: 13580919 > >> >>>>>>> > >> >>>>>>> Main area: 29646 segs, 14823 secs 14823 zones > >> >>>>>>> - COLD data: 3468, 1734, 1734 > >> >>>>>>> - WARM data: 12954, 6477, 6477 > >> >>>>>>> - HOT data: 28105, 14052, 14052 > >> >>>>>>> - Dir dnode: 29204, 14602, 14602 > >> >>>>>>> - File dnode: 19960, 9980, 9980 > >> >>>>>>> - Indir nodes: 29623, 14811, 14811 > >> >>>>>>> > >> >>>>>>> - Valid: 13615 > >> >>>>>>> - Dirty: 13309 > >> >>>>>>> - Prefree: 0 > >> >>>>>>> - Free: 2722 (763) > >> >>>>>>> > >> >>>>>>> GC calls: 8622 (BG: 4311) > >> >>>>>>> - data segments : 8560 > >> >>>>>>> - node segments : 62 > >> >>>>>>> Try to move 3552161 blocks > >> >>>>>>> - data blocks : 3540278 > >> >>>>>>> - node blocks : 11883 > >> >>>>>>> > >> >>>>>>> Extent Hit Ratio: 49 / 4171 > >> >>>>>>> > >> >>>>>>> Balancing F2FS Async: > >> >>>>>>> - nodes 6 in 141 > >> >>>>>>> - dents 0 in dirs: 0 > >> >>>>>>> - meta 13 in 346 > >> >>>>>>> - NATs 16983 > 29120 > >> >>>>>>> - SITs: 17 > >> >>>>>>> - free_nids: 1861 > >> >>>>>>> > >> >>>>>>> Distribution of User Blocks: [ valid | invalid | free ] > >> >>>>>>> [-----------------------------------------------|-|--] > >> >>>>>>> > >> >>>>>>> SSR: 1230719 blocks in 14834 segments > >> >>>>>>> LFS: 15150190 blocks in 29589 segments > >> >>>>>>> > >> >>>>>>> BDF: 89, avg. vblocks: 949 > >> >>>>>>> > >> >>>>>>> Memory: 6754 KB = static: 4763 + cached: 1990 > > > > ... > > > >> >> Per my understanding of f2fs internals, it should write these "cold" > >> files and > >> >> usual "hot" files to different sections (that should map internally > >> to > >> >> different allocation units). So the sections used by "cold" data > >> should almost > >> >> never get "dirty" because most of the time all their blocks become > >> free at > >> >> the same time. Of course, the files are not exactly 4MB in size so > >> the last > >> >> section of the deleted file will become dirty. If it is moved by > >> garbage > >> >> collector and becomes mixed with fresh "cold" data, then indeed it > >> might cause > >> >> some problems, I think. What is your opinion? > >> > > >> > If your fs is not fragmented, it may be as what you said, otherwise, > >> SSR will > >> > still try to reuse invalid block of other temperture segments, then > >> your cold > >> > data will be fixed with warm data too. > >> > > >> > I guess, what you are facing is the latter one: > >> > SSR: 1230719 blocks in 14834 segments > >> > >> I guess, I need to somehow disable any cleaning or SSR for my archive > >> and index > >> files. But keep the cleaning for other data and nodes. > > > > Could you test a mount option, "mode=lfs", to disable SSR? > > (I guess sqlite may suffer from logner latency due to GC though.) > > > > Seems like it's caused by SSR starting to make worse before 95% as you > > described > > below. > > Thanks, I'll run a test with a couple of SD cards over weekend. > So if I understand it correctly, GC will not cause the problems described > below, right? > I.e. it will not mix the new data with old data from dirty sections? > Longer SQLite latencies should not be a problem because the database is > written not > frequently and also it is about 200-250KB in size usually. Maybe forcing IPU > as > suggested by Chao would help sqlite, no? > However looks like setting ipu_policy to 1 has no effect when mode=lfs. > The IPU counter is still zero on my test system.
Yup, in mode=lfs, ipu will be disabled automatically. Thanks, > > >> I think the FS can get fragmented quite easily otherwise. The status > >> above is > >> captured when the FS already has problems. I think it can become > >> fragmented > >> this way: > >> 1. The archive is written until the utilization is 95%. It is written > >> separately from other > >> data and nodes thanks to the "cold" data feature. > >> 2. After hitting 95% the archive my program starts to rotate the > >> archive. The rotation > >> routine checks the free space, reported by statfs(), once a minute. If > >> it is below 5% > >> of total, then it deletes several oldest records in the archive. > >> 3. The last deleted record leaves a dirty section. This section holds > >> several blocks > >> from a record, which now becomes the oldest one. > >> 4. This section is merged with fresh "cold" or even warmer data by > >> either GC, or > >> SSR in one or more newly used sections. > >> 5. Then very soon the new oldest record is again deleted. And now we > >> have one > >> or even several dirty sections filled with blocks from a not so old > >> record. Which are > >> again merged with other records. > >> 6. All the records get fragmented after one full rotation. The > >> fragmentation gets > >> worse and worse. > >> > >> So I think the best thing to do is to have sections with "cold" data be > >> completely > >> out of all the cleaning schemes. It will clean itself by rotating. > >> Still other data and nodes might need to use some cleaning schemes. > >> Please correct me if I don't get it right. > >> > >> > Maybe we can try to alter updating policy from OPU to IPU for your > >> case to avoid > >> > performance regression of SSR and more frequently FG-GC: > >> > > >> > echo 1 > /sys/fs/f2fs/"yourdevicename"/ipu_policy > >> > >> Thanks, I'll try it! > > -- > Alexander > > ------------------------------------------------------------------------------ > _______________________________________________ > Linux-f2fs-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ------------------------------------------------------------------------------ _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
