Re: [PATCH 3/3] xfs: Fix stale data exposure when readahead races with hole punch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/09/2019 15:31, Jan Kara wrote:
<>
>>> Is there a test on xfstests to demonstrate this race?
>>
>> No, but I can try to create one.
> 
> I was experimenting with this but I could not reproduce the issue in my
> test VM without inserting artificial delay at appropriate place... So I
> don't think there's much point in the fstest for this.
> 
> 								Honza
> 

If I understand correctly you will need threads that direct-write
files, then fadvise(WILL_NEED) - in parallel to truncate (punch_hole) these
files - In parallel to trash caches.
(Direct-write is so data is not present in cache when you come to WILL_NEED
 it into the cache, otherwise the xfs b-trees are not exercised. Or are you
 more worried about the page_cache races?
)

Also the d-writes might want to exercise multiple size extents + holes as
well.

I have a very different system but its kind of the test we did for this
problem.

The reason it is never hit is because fadvise(WILL_NEED) is never really
used that much, and there are no applications that actually blindly truncate
during IO, this is only us in testing that do this meaningless thing.

Thanks Jan again for working on this
Boaz




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux