On Mon, Feb 11, 2019 at 10:07 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Mon, Feb 11, 2019 at 09:22:58AM -0800, Dan Williams wrote: > > > I honestly don't like the idea that random subsystems can pin down > > file blocks as a side effect of gup on the result of mmap. Recall that > > it's not just RDMA that wants this guarantee. It seems safer to have > > the file be in an explicit block-allocation-immutable-mode so that the > > fallocate man page can describe this error case. Otherwise how would > > you describe the scenarios under which FALLOC_FL_PUNCH_HOLE fails? > > I rather liked CL's version of this - ftruncate/etc is simply racing > with a parallel pwrite - and it doesn't fail. > > But it also doesnt' trucate/create a hole. Another thread wrote to it > right away and the 'hole' was essentially instantly reallocated. This > is an inherent, pre-existing, race in the ftrucate/etc APIs. If options are telling the truth with a potentially unexpected error, or lying that operation succeeded when it will be immediately undone, I'd choose the former.
