Subject: Re: nfs question - ftruncate vs pwrite
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Kenny Simpson <theonetruekenny@yahoo.com>
Cc: Peter Staubach <staubach@redhat.com>,
       linux kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <1134017608.8002.55.camel@lade.trondhjem.org>
References: <20051207215040.15310.qmail@web34106.mail.mud.yahoo.com>
	 <1134017608.8002.55.camel@lade.trondhjem.org>
Content-Type: text/plain
Date: Thu, 08 Dec 2005 00:00:00 -0500
Message-Id: <1134018000.8002.58.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2027
Lines: 49

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/

-
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/