On Mon, Jan 20, 2020 at 2:03 PM Jan Kara <jack@xxxxxxx> wrote: > > Hi Amir! > > On Fri 17-01-20 12:50:58, Amir Goldstein wrote: > > On Thu, Aug 29, 2019 at 4:10 PM Jan Kara <jack@xxxxxxx> wrote: > > > > > > Hello, > > > > > > this is a patch series that addresses a possible race between readahead and > > > hole punching Amir has discovered [1]. The first patch makes madvise(2) to > > > handle readahead requests through fadvise infrastructure, the third patch > > > then adds necessary locking to XFS to protect against the race. Note that > > > other filesystems need similar protections but e.g. in case of ext4 it isn't > > > so simple without seriously regressing mixed rw workload performance so > > > I'm pushing just xfs fix at this moment which is simple. > > > > > > > Could you give a quick status update about the state of this issue for > > ext4 and other fs. I remember some solutions were discussed. > > Shortly: I didn't get to this. I'm sorry :-|. I'll bump up a priority but I > can't promise anything at the moment. > > > Perhaps this could be a good topic for a cross track session in LSF/MM? > > Maybe although this is one of the cases where it's easy to chat about > possible solutions but somewhat tedious to write one so I'm not sure how > productive that would be. BTW my discussion with Kent [1] is in fact very > related to this problem (the interval lock he has is to stop exactly races > like this). > Well, I was mostly interested to know if there is an agreement on the way to solve the problem. If we need to discuss it to reach consensus than it might be a good topic for LSF/MM. If you already know what needs to be done, there is no need for a discussion. > > Aren't the challenges posed by this race also relevant for RWF_UNCACHED? > > Do you have anything particular in mind? I don't see how RWF_UNCACHED would > make this any better or worse than DIO / readahead... > Not better nor worse. I meant that RFW_UNCACHED is another case that would suffer the same races. Thanks, Amir.
