Thank you Chao, I will do the test based on your suggestion. Thanks,
Bintian On 2015/7/31 18:49, Chao Yu wrote: > Hi Bintian, > >> -----Original Message----- >> From: He YunLei [mailto:[email protected]] >> Sent: Friday, July 31, 2015 10:29 AM >> To: [email protected]; Jaegeuk Kim >> Cc: Chao Yu; [email protected]; Bintian >> Subject: [f2fs-dev] Data lost in Android app for not write new checkpoint >> >> Hi all, >> Recently I did some test with f2fs on my Android phone, and found a >> problem >> which I didn't know how to tackle it. >> I use my Android phone with /data partition formatted by mkfs.f2fs. >> When the >> phone just started, I check the f2fs status by reading the file >> /sys/kernel/debug/f2fs/status >> in debugfs. >> >> CP calls: 10 >> GC calls: 19 (BG: 19) >> - data segments : 19 (19) >> - node segments : 0 (0) >> >> We can see /data partition has done 10 times write_checkpoint since >> f2fs is mounted >> on the phone, it also has triggered 19 times background GC. >> >> ****** >> >> Here I took some photos consecutively, and check the file >> /sys/kernel/debug/f2fs/status again >> >> ****** >> >> CP calls: 10 >> GC calls: 20 (BG: 20) >> - data segments : 20 (20) >> - node segments : 0 (0) >> >> there is no change in CP calls number and background GC doesn't write >> new checkpoint. >> if then a sudden power failure or system crash occur, the photos will be >> lost when the phone >> restart, and a sync before crash will avoid the data lost. >> I think this problem is bad for user experience of using Android phone >> with f2fs. >> How do we deal with such situation? I wish you and other developers in this >> list could help >> me in a correct way. > > IMO, it's better to figure out whether this is a bug of f2fs first or not. > > You can enable some traces in f2fs to see whether fsync is called or not. > > enable trace by: > echo 1 > /sys/kernel/debug/tracing/events/f2fs/f2fs_sync_file_enter/enable > echo 1 > /sys/kernel/debug/tracing/events/f2fs/f2fs_sync_file_exit/enable > print trace by: > cat /sys/kernel/debug/tracing/trace > > If fsync is not be called, I think in ext4 there must be the same problem, > but I guess fortunately journal commit thread save its data since it commit > transaction per 5 second by default. You can try to configure (commit=nrsec) > it with larger value for verification the issue with ext4 filesystem. > > As a quick thought, maybe we can add one commit data thread, periodically > writebacking user data written by user previously, then do checkpoint for > persistence. > > So by this way, at most, we just lose our data for last configured time of > commit period. > > Thanks, > >> >> Thanks, >> He > > > > . > ------------------------------------------------------------------------------ _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
