On Sat, 22 Nov 2008 00:53:46 +0100 Nick Piggin <npiggin@xxxxxxx> wrote: > On Fri, Nov 21, 2008 at 05:50:17PM -0500, Jeff Layton wrote: > > On Fri, 21 Nov 2008 14:38:18 -0600 > > "Steve French" <smfrench@xxxxxxxxx> wrote: > > > > > Fix attached. > > > > > > Shaggy/Jeff/Nick etc. do you want to review/ack it since it is late in the rc? > > > > > > > Talking with Steve on IRC, we thought it might be better to optimize > > away the read when possible. I think this patch should do it. We skip > > the read if the write starts past the current end of the file, or if > > the offset into the page of the beginning of the write is 0 and we're > > writing past the current end of the file. In those situations we just > > zero out the rest of the page. > > > > Combined patch inlined below. I also took the liberty of adding a page > > pointer to make the code look a little cleaner. > > > > Thoughts? > > You just have to be very careful when marking a page uptodate. This > is why I removed that earlier hunk. > > 1) the actual write may not cover as much space as we were told here. Under what circumstances would that occur? The places where write_begin and write_end get called look like they use the same lengths... > 2) the page no wlooks like this I think? > > 0 offset+len PAGE_CACHE_SIZE > |---- uninitialized data ---|---- zeroes ---| > > Then if you SetPageUptodate, if you are using the generic_mapping_read, > it can come and read the page even without locking it. If you are > not using the generic pagecache operations at all, then you could do > something like this if you are careful, but it still seems a bit > risky. > > Or am I wrong about the data being uninitialized? Bear with me here -- page flag handling makes me dizzy... The latest patch that I sent only skips the read if: 1) the page lies beyond the current end of the file 2) if the page sits on top of the end of the file and the write would overwrite all of the data that we would read in. The first part should be OK I think. A pagecache read should not be able to go beyond EOF, should it? The second one is a problem. Ideally we'd like to be able to get away w/o doing a read in that case, but I guess we'd have to delay setting the page uptodate until after the write data has been copied to it. cifs_write_end seems to expect that the page is uptodate when it gets it though. For now, we can probably do the safe thing and perform a read in that case, but it would certainly be nice to avoid it. Is there some way that we can? Thanks, -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
