Re: Data lost in Android app for not write new checkpoint

[Chao Yu <chao2.yu@samsung.com>]

Hi Bintian,

> -----Original Message-----
> From: He YunLei [mailto:heyunlei@huawei.com]
> Sent: Friday, July 31, 2015 10:29 AM
> To: linux-f2fs-devel@lists.sourceforge.net; Jaegeuk Kim
> Cc: Chao Yu; cm224.lee@samsung.com; 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



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