mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kenny Simpson <theonetruekenny@yahoo.com>
To: linux kernel <linux-kernel@vger.kernel.org>
Subject: nfs question - ftruncate vs pwrite
Date: Wed, 7 Dec 2005 12:46:12 -0800 (PST)	[thread overview]
Message-ID: <20051207204612.70808.qmail@web34114.mail.mud.yahoo.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Sorry about the previous partial message...

If a file is extended via ftruncate, the new empty pages are read in before the the ftruncate
returns (taking 64mS on my machine), but if the file is extended via pwrite, nothing is read in
and the system call is very quick (34uS).

Why is there such a difference?  Is there another cheap way to grow a file and map in its new
pages?  Am I missing some other semantic difference between ftruncate and a pwrite past the end of
the file?

Here is a test program.. compile with -DABUSE to get the pwrite version.

thanks,
-Kenny


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 862959384-dtest.c --]
[-- Type: text/x-csrc; name="dtest.c", Size: 1379 bytes --]

#define _GNU_SOURCE

#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#include <stdio.h>
#include <string.h>
#include <malloc.h>

int main(int argc, char* argv[])
{
  int fd;
  unsigned long long int const size = 4096 * 1024;
  unsigned int const size_page = 1024;
  unsigned long long int offset = 0;
  unsigned int offset_page = 0;

  //char* buffer = valloc(size);
  //memset(buffer, 0, size);

  if (argc != 2) {
    printf("usage: %s <filename>\n", argv[0]);
    return 0;
  }

  fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC | O_LARGEFILE /*| O_DIRECT*/, 0644);
  if (fd < 0) {
    perror("open");
    return 0;
  }

#ifdef ABUSE
  pwrite64(fd, "" , 1, offset + size);
#else
  ftruncate64(fd, offset + size);
#endif

  char* mapping = (char*)mmap64(0, size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE | MAP_NONBLOCK, fd, offset);
  memset(mapping, 'a', size);

  for (;;) {
    offset += size;
    offset_page += size_page;

#ifdef ABUSE
    pwrite64(fd, "", 1, offset + size);
#else
    ftruncate64(fd, offset + size);
#endif

    //munmap(mapping, size);
    //mapping = (char*)mmap64(0, size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE | MAP_NONBLOCK, fd, offset);
    remap_file_pages(mapping, size, 0, offset_page, MAP_NONBLOCK);

    memset(mapping, 'a', size);
  }

  close(fd);

  return 0;
}

             reply	other threads:[~2005-12-07 20:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-07 20:46 Kenny Simpson [this message]
2005-12-07 21:14 ` Peter Staubach
2005-12-07 21:50   ` Kenny Simpson
2005-12-08  4:53     ` Trond Myklebust
2005-12-08  5:00       ` Trond Myklebust
2005-12-08 16:15       ` Kenny Simpson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051207204612.70808.qmail@web34114.mail.mud.yahoo.com \
    --to=theonetruekenny@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®