Re: [f2fs-dev] Potential data corruption?

[Chao Yu <yuchao0@huawei.com>]

On 2019/12/8 21:51, Gao Xiang via Linux-f2fs-devel wrote:
> Hi,
> 
> On Sun, Dec 08, 2019 at 09:15:55PM +0800, Hongwei Qin wrote:
>> Hi,
>>
>> On Sun, Dec 8, 2019 at 12:01 PM Chao Yu <chao@kernel.org> wrote:
>>>
>>> Hello,
>>>
>>> On 2019-12-7 18:10, 锟斤拷锟秸碉拷锟斤拷锟斤拷锟斤拷 wrote:
>>>> Hi F2FS experts,
>>>> The following confuses me:
>>>>
>>>> A typical fsync() goes like this:
>>>> 1) Issue data block IOs
>>>> 2) Wait for completion
>>>> 3) Issue chained node block IOs
>>>> 4) Wait for completion
>>>> 5) Issue flush command
>>>>
>>>> In order to preserve data consistency under sudden power failure, it requires that the storage device persists data blocks prior to node blocks.
>>>> Otherwise, under sudden power failure, it's possible that the persisted node block points to NULL data blocks.
>>>
>>> Firstly it doesn't break POSIX semantics, right? since fsync() didn't return
>>> successfully before sudden power-cut, so we can not guarantee that data is fully
>>> persisted in such condition.
>>>
>>> However, what you want looks like atomic write semantics, which mostly database
>>> want to guarantee during db file update.
>>>
>>> F2FS has support atomic_write via ioctl, which is used by SQLite officially, I
>>> guess you can check its implementation detail.
>>>
>>> Thanks,
>>>
>>
>> Thanks for your kind reply.
>> It's true that if we meet power failure before fsync() completes,
>> POSIX doen't require FS to recover the file. However, consider the
>> following situation:
>>
>> 1) Data block IOs (Not persisted)
>> 2) Node block IOs (All Persisted)
>> 3) Power failure
>>
>> Since the node blocks are all persisted before power failure, the node
>> chain isn't broken. Note that this file's new data is not properly
>> persisted before crash. So the recovery process should be able to
>> recognize this situation and avoid recover this file. However, since
>> the node chain is not broken, perhaps the recovery process will regard
>> this file as recoverable?
> 
> As my own limited understanding, I'm afraid it seems true for extreme case.
> Without proper FLUSH command, newer nodes could be recovered but no newer
> data persisted.
> 
> So if fsync() is not successful, the old data should be readed
> but for this case, unexpected data (not A or A', could be random data
> C) will be considered validly since its node is ok.
> 
> It seems it should FLUSH data before the related node chain written or
> introduce some data checksum though.
> 
> If I am wrong, kindly correct me...

Yes, I guess if user wants more consistence guarantee of fsync() than posix one,
we can refactor fsync_mode=strict mode a bit to handle fsync() IOs like we did
for atomic write IOs to keep strict data/node IO order. But note that such
consistence guarantee is weak, after sudden power-cut, recovered file may
contain mixed old and new data (fsynced data partially persisted) which may also
crash the Apps.

Thanks,

> 
> Thanks,
> Gao Xiang
> 
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel