public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Caching files in nfsd was Re: [patch 12/16] fix race between writeback and unlink
Date: 04 Jun 2002 12:38:25 +0200	[thread overview]
Message-ID: <p73r8jncori.fsf_-_@oldwotan.suse.de> (raw)
In-Reply-To: <1023142233.31475.23.camel@tiny.suse.lists.linux.kernel> <Pine.LNX.4.44.0206031514110.868-100000@home.transmeta.com.suse.lists.linux.kernel>

Linus Torvalds <torvalds@transmeta.com> writes:

> I _think_ that right now nfsd doesn't cache file opens (only inodes), so
> this could be a performance issue for nfsd, but it might be possible to
> change how nfsd acts. And it would be a _lot_ cleaner to do it at the file
> level.

Yes.

Fixing this would also help XFS (which I hope will be merged in 2.5 as
it works very well for a lot of people). It manages its extent
preallocation per file and flushes extents on closes. Currently it has
to maintain an ugly private nfs reference cache to avoid flushing an
extent after every NFS write operation (and killing write performance
this way)

Also letting nfsd know about the filemap.c readahead window information in 
struct file (that is what it currently caches in the racache) is really ugly
and a kind of layering violation...

I guess it is not too uncommon for other file systems too to hold state 
per open file.

-Andi

       reply	other threads:[~2002-06-04 10:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1023142233.31475.23.camel@tiny.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.44.0206031514110.868-100000@home.transmeta.com.suse.lists.linux.kernel>
2002-06-04 10:38   ` Andi Kleen [this message]
2002-06-04 11:37     ` Caching files in nfsd was Re: [patch 12/16] fix race between writeback and unlink Neil Brown
2002-06-04 12:16       ` Andi Kleen
2002-06-04 13:29         ` Chris Mason

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=p73r8jncori.fsf_-_@oldwotan.suse.de \
    --to=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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