On Fri, 2009-05-29 at 13:48 -0400, Peter Staubach wrote: > Trond Myklebust wrote: > > Look... This happens when you _flush_ the file to stable storage if > > there is only a single write < wsize. It isn't the business of the NFS > > layer to decide when you flush the file; that's an application > > decision... > > > > > > I think that one easy way to show why this optimization is > not quite what we would all like, why there only being a > single write _now_ isn't quite sufficient, is to write a > block of a file and then read it back. Things like > compilers and linkers might do this during their random > access to the file being created. I would guess that this > audit thing that Brian has refered to does the same sort > of thing. > > ps > > ps. Why do we flush dirty pages before they can be read? > I am not even clear why we care about waiting for an > already existing flush to be completed before using the > page to satisfy a read system call. We only do this if the page cannot be marked as up to date. i.e. there have to be parts of the page which contain valid data on the server, and that our client hasn't read in yet, and that aren't being overwritten by our write. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
