Re: video archive on a microSD card

[Jaegeuk Kim <jaegeuk@kernel.org>]

On Mon, Aug 29, 2016 at 03:23:06PM +0300, Alexander Gordeev wrote:
> Hi Jaegeuk,
> 
> 27.08.2016, 04:20, "Jaegeuk Kim" <jaegeuk@kernel.org>:
> > On Thu, Aug 25, 2016 at 11:14:03PM +0300, Alexander Gordeev wrote:
> >>  Hi Jaegeuk,
> >>
> >>  Thanks for all the help!
> >>...
> >>  > This is the number of dirty segments, so it needs to consider section and
> >>  > segment at the same time; a dirty section can consist of valid and free
> >>  > segments.
> >>  > How abouting testing 2MB-sized section which is the default option?
> >>
> >>  I tried what you said. Still the majority of segments are dirty for some reason:
> >>
> >>  =====[ partition info(sda). #0, RW]=====
> >>  [SB: 1] [CP: 2] [SIT: 6] [NAT: 114] [SSA: 116] [MAIN: 59149(OverProv:3003 Resv:48)]
> >>
> >>  Utilization: 10% (3013093 valid blocks)
> >>    - Node: 3528 (Inode: 548, Other: 2980)
> >>    - Data: 3009565
> >>    - Inline_xattr Inode: 0
> >>    - Inline_data Inode: 0
> >>    - Inline_dentry Inode: 0
> >>    - Orphan Inode: 0
> >>
> >>  Main area: 59149 segs, 59149 secs 59149 zones
> >>    - COLD data: 7183, 7183, 7183
> >>    - WARM data: 6654, 6654, 6654
> >>    - HOT data: 59134, 59134, 59134
> >>    - Dir dnode: 59127, 59127, 59127
> >>    - File dnode: 59125, 59125, 59125
> >>    - Indir nodes: 59129, 59129, 59129
> >>
> >>    - Valid: 300
> >>    - Dirty: 6438
> >>    - Prefree: 0
> >>    - Free: 52411 (52411)
> >>
> >>  CP calls: 1023 (BG: 473)
> >>  GC calls: 470 (BG: 470)
> >>    - data segments : 466 (466)
> >>    - node segments : 4 (4)
> >>  Try to move 152221 blocks (BG: 152221)
> >>    - data blocks : 151417 (151417)
> >>    - node blocks : 804 (804)
> >>
> >>  Extent Cache:
> >>    - Hit Count: L1-1:6262 L1-2:0 L2:0
> >>    - Hit Ratio: 2% (6262 / 273606)
> >>    - Inner Struct Count: tree: 292(0), node: 8
> >>
> >>  Balancing F2FS Async:
> >>    - inmem: 0, wb_bios: 0
> >>    - nodes: 0 in 0
> >>    - dents: 0 in dirs: 0 ( 0)
> >>    - datas: 0 in files: 0
> >>    - meta: 0 in 0
> >>    - NATs: 0/ 43
> >>    - SITs: 0/ 59149
> >>    - free_nids: 3414
> >>
> >>  Distribution of User Blocks: [ valid | invalid | free ]
> >>    [-----|--|-------------------------------------------]
> >>
> >>  IPU: 0 blocks
> >>  SSR: 0 blocks in 0 segments
> >>  LFS: 3691542 blocks in 7208 segments
> >>
> >>  BDF: 95, avg. vblocks: 444
> >>
> >>  Memory: 12662 KB
> >>    - static: 12597 KB
> >>    - cached: 64 KB
> >>    - paged : 0 KB
> >>
> >>  But the archive is working perfectly as before.
> >
> > Okay, so we need to gather more information about IO traces. :)
> >
> > Could you get them by:
> >
> > echo 1 > /sys/kernel/debug/tracing/events/f2fs/f2fs_submit_write_bio/enable
> > echo 1 > /sys/kernel/debug/tracing/events/f2fs/f2fs_submit_page_mbio/enable
> > echo 1 > /sys/kernel/debug/tracing/tracing_on
> > cat /sys/kernel/debug/tracing/trace_pipe
> >
> > You can get a script in f2fs-tools.git/scripts/tracepoint.sh
> 
> I collected the trace. It is attached. Thanks!

Thanks.

What I've found from your trace are:
- there are two files (ino=17690, ino=17691) which shared the data log.
- ino=17690 writes data sequentiallly, and ino=17691 writes small data randomly.
- ino=17690 writes misaligned 4KB blocks at every around 296KB which produces
 dirty segments.

Could you check all the writes and truncation in your app are aligned to 4KB?
And, if ino=17691 is sqlite, it needs to check whether it is reaaly using other
data log.

Thanks,

> 
> -- 
>  Alexander



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