Re: [PATCH v2 3/3] generic/470: add syncfs test

[Amir Goldstein <amir73il@gmail.com>]

On Mon, Dec 11, 2017 at 4:31 PM, Chengguang Xu <cgxu519@icloud.com> wrote:
>
>> 在 2017年12月11日，下午9:20，Chengguang Xu <cgxu519@icloud.com> 写道：
>>
>>>
>>> 在 2017年12月11日，下午8:44，Amir Goldstein <amir73il@gmail.com> 写道：
>>>
>>> On Mon, Dec 11, 2017 at 2:33 PM, Chengguang Xu <cgxu519@icloud.com> wrote:
>>>>>
>>>>> 在 2017年12月11日，下午6:46，Amir Goldstein <amir73il@gmail.com> 写道：
>>>>>
>>>>> On Mon, Dec 11, 2017 at 12:03 PM, Chengguang Xu <cgxu519@icloud.com> wrote:
>>>>>>>
>>>>>>> 在 2017年12月7日，下午4:17，Amir Goldstein <amir73il@gmail.com> 写道：
>>>>> [...]
>>>>>>
>>>>>> I did more detail tests for three different data modes of ext4 and found
>>>>>> the overlayfs syncfs bug is reproducible on data=ordered and data=writeback,
>>>>>> but on data=journal mode, data is flushed and correct.
>>>>>
>>>>> That is expected, because overlayfs does call upper's sync_fs() method and
>>>>> for journal=data that will flush all dirty pages as well.
>>>>>
>>>>>> I only wrote only a few words
>>>>>> to a single file and the bug is always reproducible on my test environment.
>>>>>>
>>>>>> For writeback interferences, AFAIK, from dirty ratio and period.
>>>>>> If we drop all dirty caches & sync before the test, I think we can
>>>>>> avoid interference from it.
>>>>>>
>>>>>
>>>>> Why? does either drop_caches or sync() reset the flusher thread
>>>>> periodic flush dirty pages?
>>>>
>>>> Sorry，We have to finish test in 30 seconds after we write test file,
>>>> otherwise may be affected by background flusher.
>>>>
>>>>
>>>>>
>>>>>> So if we don’t have anything else to interference test result,
>>>>>> I just want to modify to write a small single file as test target.
>>>>>>
>>>>>> Am I missing anything?
>>>>>
>>>>> I think the chance of flusher thread interfering the test and
>>>>> flushing the dirty page you wrote before _scratch_shutdown exists,
>>>>> but is small enough so we can neglect it and keep the test as simple
>>>>> as possible.
>>>>
>>>> As I know, in normal case flusher thread check dirty inode expiring every 5 seconds(default) and flush dirty
>>>> inode when expires 30 seconds(default). If we can finish test in 30s after running test, it would be OK.
>>>> What do you think?
>>>>
>>>
>>> 5 seconds is ext4 default journal commit interval. this is when dirty
>>> metadata will be flushed.
>>> 30 is generic flusher thread interval.
>>> What if test started 29 seconds after last flush?
>>
>> Maybe we have misunderstanding about the flushing intervals.
>> I’m saying the intervals which are under /proc/sys/vm to control
>> writeback behaviors, it seems not related to any specific filesystem
>> like ext4 or others.
>>
>> dirty_expire_interval
>> default:3000(millisecond)
>>
>> dirty_writeback_interval
>> default:500(millisecond)
>
> Correction:
>
> dirty_expire_interval
> default:3000(centiseconds)
>
> dirty_writeback_interval
> default:500(centiseconds)
>
>

Right. I was confusing the 2 different tunables.
I agree your test should be fine with simple small write after sync
in an isolated test environment.

Amir.