Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1670378
| From | Christoph Hellwig <hch@lst.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 1/2] mm: introduce bmap_walk() |
| Date | 2017-06-20 09:40 +0200 |
| Message-ID | <tUlVv-5Fd-7@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <tTaIN-8fC-3@gated-at.bofh.it> <tTet4-2tH-3@gated-at.bofh.it> <tTl1v-72O-5@gated-at.bofh.it> <tTDhL-2iQ-1@gated-at.bofh.it> <tU9B1-6dJ-33@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC PATCH 1/2] mm: introduce bmap_walk() Dan Williams <dan.j.williams@intel.com> - 2017-06-17 03:30 +0200
Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Christoph Hellwig <hch@lst.de> - 2017-06-17 07:30 +0200
Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Dan Williams <dan.j.williams@intel.com> - 2017-06-17 14:30 +0200
Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Christoph Hellwig <hch@lst.de> - 2017-06-18 10:00 +0200
Re: [RFC PATCH 1/2] mm: introduce bmap_walk() "Darrick J. Wong" <darrick.wong@oracle.com> - 2017-06-19 18:20 +0200
Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-19 20:30 +0200
Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Christoph Hellwig <hch@lst.de> - 2017-06-20 09:40 +0200
csiph-web