On Wed, 2005-12-07 at 13:50 -0800, Kenny Simpson wrote:
> --- Peter Staubach <[email protected]> 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. 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
