On Mon, Jun 19, 2017 at 07:19:57PM +0100, Al Viro wrote: > Speaking of iomap, what's supposed to happen when doing a write into what > used to be a hole? Suppose we have a file with a megabyte hole in it > and there's some process mmapping that range. Another process does > write over the entire range. We call ->iomap_begin() and allocate > disk blocks. Then we start copying data into those. In the meanwhile, > the first process attempts to fetch from address in the middle of that > hole. What should happen? Right now the buffered iomap code expects delayed allocations. So ->iomap_begin will only reserve block in memory, and not even mark the blocks as allocated in the page / buffer_head. The fact that the block is allocated is only propagated into the page buffer_head on a page by page basis in the actor. > Should the blocks we'd allocated in ->iomap_begin() be immediately linked > into the whatever indirect locks/btree/whatnot we are using? That would > require zeroing all of them first - otherwise that readpage will read > uninitialized block. Another variant would be to delay linking them > in until ->iomap_end(), but... Suppose we get the page evicted by > memory pressure after the writer is finished with it. If ->readpage() > comes before ->iomap_end(), we'll need to somehow figure out that it's > not a hole anymore, or we'll end up with an uptodate page full of zeroes > observed by reads after successful write(). Delayed blocks are ignored by the read code, so it will read 'through' them. > The comment you've got in linux/iomap.h would seem to suggest the second > interpretation, but neither it nor anything in Documentation discusses the > relations with readpage/writepage... I'll see if I can come up with some better documentation.
