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;
}
next 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®