From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: quinn@nmt.edu (Quinn Harris),
linux-kernel@vger.kernel.org (linux-kernel@vger.kernel.org),
acahalan@cs.uml.edu
Subject: Re: File copy system call proposal
Date: Mon, 10 Dec 2001 18:44:43 MET-1 [thread overview]
Message-ID: <B9C4D5C2F78@vcnet.vc.cvut.cz> (raw)
On 10 Dec 01 at 16:19, Daniel Phillips wrote:
> On December 10, 2001 06:44 am, Albert D. Cahalan wrote:
> >
> > No, mmap+write does not do the job. SMB file servers have
> > a remote copy operation. There shouldn't be any need to
> > pull data over the network only to push it back again!
>
> Hi Albert,
>
> I don't get it, you're saying that this zero-copy optimization, which happens
> entirely within the vfs, shouldn't be done because smb can't do it over a
> network?
VFS can do this optimization (but why...), but having FS-specific
sendfile would be nice too - FS can verify whether both source & destination
are on same filesystem, and if they do, it can perform server filecopy
(if server's implementation filecopy can copy arbitrary long chunk at
arbitrary offset into another file at some else offset, like Netware's
NWFileServerFileCopy() does).
> > trustees (NetWare)
>
> I'd think the mmap-based copy would only use the technique on the data
> portion of a file.
At least from my exprience with Netware I can say that copy which copies
file trustees happens in at most 1% of all copies (and on Netware
trustees flow through the tree down, so you have usually no trustees
assigned to leaf files) - and this 1% is when you do backup and restore.
In all other cases it would be great surprise that all users which had
rights to old copy have these rights to new copy too.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
next reply other threads:[~2001-12-10 17:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-10 18:44 Petr Vandrovec [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-12-08 3:42 File copy system call proposal Quinn Harris
2001-12-08 4:00 ` H. Peter Anvin
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 4:25 ` Christian Lavoie
[not found] ` <1007833194.17577.0.camel@buffy>
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
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=B9C4D5C2F78@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=acahalan@cs.uml.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@bonn-fries.net \
--cc=quinn@nmt.edu \
/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