From: Mike Fedyk <mfedyk@matchmail.com>
To: Andi Kleen <ak@suse.de>
Cc: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
"David S. Miller" <davem@redhat.com>,
taka@valinux.co.jp, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] zerocopy NFS updated
Date: Mon, 15 Apr 2002 17:17:49 -0700 [thread overview]
Message-ID: <20020416001749.GY23513@matchmail.com> (raw)
In-Reply-To: <20020411.164134.85392767.taka@valinux.co.jp> <20020411.203823.67879801.taka@valinux.co.jp> <20020411.043614.02328218.davem@redhat.com> <200204111257.g3BCvOX10348@Port.imtp.ilyichevsk.odessa.ua> <20020411151616.A1239@wotan.suse.de>
On Thu, Apr 11, 2002 at 03:16:16PM +0200, Andi Kleen wrote:
> On Thu, Apr 11, 2002 at 04:00:37PM -0200, Denis Vlasenko wrote:
> > On 11 April 2002 09:36, David S. Miller wrote:
> > > No, you must block truncate operations on the file until the client
> > > ACK's the nfsd read request if you wish to use sendfile() with
> > > nfsd.
> >
> > Which shouldn't be a big performance problem unless I am unaware
> > of some real-life applications doing heavy truncates.
>
> Every unlink does a truncate. There are applications that delete files
> a lot.
Is this true at the filesystem level or only in memory? If so, I could
immagine that it would make it much harder to undelete a file when you don't
even know how big it was (file set to 0 size)...
Why is this required? Could someone say quickly (as I'm sure it's probably
quite complex) or point me to some references?
next prev parent reply other threads:[~2002-04-16 0:15 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020410.190550.83626375.taka@valinux.co.jp.suse.lists.linux.kernel>
2002-04-10 19:32 ` [PATCH] zerocopy NFS updated Andi Kleen
2002-04-11 2:30 ` David S. Miller
2002-04-11 6:46 ` Hirokazu Takahashi
2002-04-11 6:48 ` David S. Miller
2002-04-11 7:41 ` Hirokazu Takahashi
2002-04-11 7:52 ` David S. Miller
2002-04-11 11:38 ` Hirokazu Takahashi
2002-04-11 11:36 ` David S. Miller
2002-04-11 18:00 ` Denis Vlasenko
2002-04-11 13:16 ` Andi Kleen
2002-04-11 17:36 ` Benjamin LaHaise
2002-04-16 0:17 ` Mike Fedyk [this message]
2002-04-16 15:37 ` Oliver Xymoron
2002-04-11 17:33 ` Benjamin LaHaise
2002-04-12 8:10 ` Hirokazu Takahashi
2002-04-12 12:30 ` Hirokazu Takahashi
2002-04-12 12:35 ` Andi Kleen
2002-04-12 21:22 ` Jamie Lokier
2002-04-12 21:31 ` David S. Miller
2002-04-13 0:21 ` Jamie Lokier
2002-04-13 6:39 ` Andi Kleen
2002-04-13 8:01 ` Hirokazu Takahashi
2002-04-13 19:19 ` Eric W. Biederman
2002-04-13 19:37 ` Andi Kleen
2002-04-13 20:34 ` Eric W. Biederman
2002-04-24 23:11 ` Mike Fedyk
2002-04-25 17:11 ` Andreas Dilger
2002-04-13 18:52 ` Chris Wedgwood
2002-04-14 0:07 ` Keith Owens
2002-04-14 8:19 ` Chris Wedgwood
2002-04-14 8:40 ` Keith Owens
2002-04-12 21:39 ` David S. Miller
2002-04-15 1:30 ` Hirokazu Takahashi
2002-04-15 4:23 ` David S. Miller
2002-04-16 1:03 ` Hirokazu Takahashi
2002-04-16 1:41 ` Jakob Østergaard
2002-04-16 2:20 ` Hirokazu Takahashi
2002-04-18 5:01 ` Hirokazu Takahashi
2002-04-18 7:58 ` Jakob Østergaard
2002-04-18 8:53 ` Trond Myklebust
2002-04-19 3:21 ` Hirokazu Takahashi
2002-04-19 9:18 ` Trond Myklebust
2002-04-20 7:47 ` Hirokazu Takahashi
2002-04-25 12:37 ` Possible bug with UDP and SO_REUSEADDR. Was " Terje Eggestad
2002-04-26 2:43 ` David S. Miller
2002-04-26 7:38 ` Terje Eggestad
2002-04-29 0:41 ` Possible bug with UDP and SO_REUSEADDR David Schwartz
2002-04-29 8:06 ` Terje Eggestad
2002-04-29 8:44 ` David Schwartz
2002-04-29 10:03 ` Terje Eggestad
2002-04-29 10:38 ` David Schwartz
2002-04-29 14:20 ` Terje Eggestad
[not found] ` <200204192128.QAA24592@popmail.austin.ibm.com>
2002-04-20 10:14 ` [PATCH] zerocopy NFS updated Hirokazu Takahashi
2002-04-20 15:49 ` Andrew Theurer
2002-04-10 10:05 Hirokazu Takahashi
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=20020416001749.GY23513@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=ak@suse.de \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=taka@valinux.co.jp \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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