Re: nfs question - ftruncate vs pwrite

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2005-12-07 at 23:53 -0500, Trond Myklebust wrote:
> On Wed, 2005-12-07 at 13:50 -0800, Kenny Simpson wrote:
> > --- Peter Staubach <staubach@redhat.com> wrote:
> > > You might use tcpdump or etherreal to see what the different traffic looks
> > > like.  I suspect that ftruncate() leads a SETATTR operation while pwrite()
> > > leads to a WRITE operation.
> > 
> > Ethereal results interpreted with wild speculation:
> > The pwrite case:
> >   This does a bunch of reads, but the server always returns a short read responding with EOF.  It
> > seems that a pwrite does cause a getattr call, but that's it.
> >   Once memory is exhausted, the pages are written out.
> > 
> > The ftruncate case:
> >   This does a setattr, then does a read - this time the server responds with a large amount of
> > 0's.
> 
> That is as expected. The ftruncate() causes an immediate change in
> length of the file on the server, and so reads will.

...Err... 

...and so reads of the empty pages will succeed.

>  In the case of
> pwrite(), that is cached on the client until you fsync/close, and so the
> server returns short reads.
>
> > Since this is using the buffer cache (not opened with O_DIRECT), and since we know we are
> > extending the file... is it strictly necessary to read in pages of 0's from the server?
> 
> Possibly not, but is this a common case that is worth optimising for?
> Note that use of the standard write() syscall as opposed to mmap() will
> not trigger this avalanche of page-ins.
> 
> Cheers,
>   Trond
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/