From: Quinn Harris <quinn@nmt.edu>
To: linux-kernel@vger.kernel.org
Subject: File copy system call proposal
Date: 07 Dec 2001 20:42:36 -0700 [thread overview]
Message-ID: <1007782956.355.2.camel@quinn.rcn.nmt.edu> (raw)
I would like to propose implementing a file copy system call.
I expect the initial reaction to such a proposal would be "feature
bloat" but I believe some substantial benefits can be seen possibly
making it worthwhile, primarily the following:
Copy on write:
>From my experience most files that are copied on the same partition are
copied from a source code directory (eg /usr/src/{src dir}) to somewhere
else in /usr. These copied files are seldomly modified but usually
truncated (when copied over again).
Instead of actually copying the file in these circumstances something
similar to a hard link could be created. But unlike a hard link, when
data is written to the file a real duplicate of the file (or possibly
part of the file) will be created. This is basically identical to the
way a processes memory space is duplicated on a fork. To create an
illusion of an actual copied file the file system will need to
explicitly support this feature. This can also eliminate duplication in
the buffer cache when a file is copied.
This feature would drastically reduce the time taken to install a
program from a compiled source tarball. I also expect on my system this
feature would save about 1/6 of my hard drive space. Of course this
wouldn't affect performance if the source and destination files are on
different partitions.
All kernel copy:
Commands like cp and install open the source and destination file using
the open sys call. The data from the source is copied to the
destination by repeatedly calling the read then write sys calls. This
process involves copying the data in the file from kernel memory space
to the user memory space and back again. Note that all this copying is
done by the kernel upon calling read or write. I would expect if this
can be moved completely into the kernel no memory copy operations would
be performed by the processor by using hardware DMA.
On my system a copy takes about 1s of the CPU time per 20MB copied (PII
300Mhz) much of which I expect is spent just copying memory. This
figure seems a bit high to copy memory so someone please correct me if I
am wrong.
Implementing these features especially the copy on write I expect will
not be trivial. In addition code that copies files like cp must be
modified to take advantage of these features.
Will many other users benefit from these features? Will implementing
them (especially copy on write) cause an excessive addition to the code
of the kernel?
Quinn Harris (quinn@nmt.edu)
next reply other threads:[~2001-12-08 3:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1007833194.17577.0.camel@buffy>
2001-12-08 3:42 ` Quinn Harris [this message]
2001-12-08 4:00 ` H. Peter Anvin
2001-12-08 4:25 ` Christian Lavoie
2001-12-08 6:03 ` Quinn Harris
2001-12-08 13:57 ` Daniel Phillips
2001-12-09 0:19 ` H. Peter Anvin
2001-12-09 4:56 ` Quinn Harris
2001-12-10 5:44 ` Albert D. Cahalan
2001-12-09 20:25 ` Hans Reiser
2001-12-10 15:19 ` Daniel Phillips
2001-12-13 10:01 ` Andreas Dilger
2001-12-13 21:17 ` Pavel Machek
2001-12-19 20:26 ` Daniel Phillips
2001-12-20 10:09 ` Pavel Machek
2001-12-20 13:38 ` Svein Ove Aas
2001-12-20 13:53 ` Jakob Østergaard
2001-12-20 14:00 ` Jakob Østergaard
2001-12-23 1:19 ` Pavel Machek
2001-12-20 14:31 ` David Woodhouse
2001-12-20 15:06 ` George Greer
2001-12-20 15:07 ` David Woodhouse
2001-12-20 21:32 ` Jamie Lokier
2001-12-08 19:23 ` Quinn Harris
2001-12-08 23:11 ` Ton Hospel
2001-12-09 15:35 ` Pavel Machek
2001-12-10 11:50 ` Albert D. Cahalan
2001-12-10 2:49 ` Hans Reiser
2001-12-10 12:13 ` Pavel Machek
2001-12-10 15:20 ` vda
2001-12-10 18:44 Petr Vandrovec
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=1007782956.355.2.camel@quinn.rcn.nmt.edu \
--to=quinn@nmt.edu \
--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®