All of lore.kernel.org
 help / color / mirror / Atom feed
From: <trond.myklebust@fys.uio.no>
To: <pausmith@nortelnetworks.com>
Cc: <nfs@lists.sourceforge.net>
Subject: Re: NFS client write performance issue ... thoughts?
Date: Fri, 9 Jan 2004 22:30:24 +0100 (CET)	[thread overview]
Message-ID: <32997.141.211.133.197.1073683824.squirrel@webmail.uio.no> (raw)

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

På to , 08/01/2004 klokka 12:47, skreiv Paul Smith:
> Do you know when those accounting errors were fixed?

In the official kernels? 2.4.22, I believe... However there are patches
going back to 2.4.19...

See http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.19/

The main patch you want will be linux-2.4.19-14-call_start.dif

>
> ClearCase implements its own virtual filesystem type, and so is
> heavily tied to specific kernels (the kernel module is not open source
> of course :( ).  We basically can move to any kernel that has been
> released as part of an official Red Hat release (say, 2.4.20-8 from
> RH9 would work), but no other kernels can be used (the ClearCase
> kernel module has checks on the sizes of various kernel structures and
> won't load if they're not what it thinks they should be--and since
> it's a filesystem it cares deeply about structures that have tended to
> change a lot.  It won't even work with vanilla kernel.org kernels of
> the same version.)

Blech...

Note: if you want to try implementing a scheme like what you propose,
then the simplest way to do it, would be to add something like the
following patch. It disables nfs_strategy(), then causes
nfs_updatepage() to extend the request size if it sees that we're not
using byte-range locking, and the complete page is in cache.

Cheers,
  Trond



[-- Attachment #2: untitled-1.2 --]
[-- Type: text/html, Size: 2822 bytes --]

[-- Attachment #3: gnurr.dif --]
[-- Type: text/plain, Size: 1214 bytes --]

--- linux-2.4.23-rc1/fs/nfs/write.c.orig	2003-11-16 19:24:23.000000000 -0500
+++ linux-2.4.23-rc1/fs/nfs/write.c	2004-01-09 16:25:18.000000000 -0500
@@ -746,6 +746,7 @@ nfs_update_request(struct file* file, st
 static void
 nfs_strategy(struct inode *inode)
 {
+#if 0
 	unsigned int	dirty, wpages;
 
 	dirty  = inode->u.nfs_i.ndirty;
@@ -760,6 +761,7 @@ nfs_strategy(struct inode *inode)
 	if (dirty >= NFS_STRATEGY_PAGES * wpages)
 		nfs_flush_file(inode, NULL, 0, 0, 0);
 #endif
+#endif
 }
 
 int
@@ -849,8 +851,19 @@ nfs_updatepage(struct file *file, struct
 		SetPageUptodate(page);
 		nfs_unlock_request(req);
 		nfs_strategy(inode);
-	} else
+	} else {
+		/* If we are not locking, and the page is up to date,
+		 * we may write out the entire page for efficiency.
+		 */
+		if (Page_Uptodate(page) && inode->i_flock == 0) {
+			req->wb_offset = 0;
+			if (page->index < (inode->i_size >> PAGE_CACHE_SHIFT))
+				req->wb_bytes = PAGE_CACHE_SIZE;
+			else
+				req->wb_bytes = inode->i_size & PAGE_CACHE_MASK;
+		}
 		nfs_unlock_request(req);
+	}
 done:
         dprintk("NFS:      nfs_updatepage returns %d (isize %Ld)\n",
                                                 status, (long long)inode->i_size);


             reply	other threads:[~2004-01-09 21:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-09 21:30 trond.myklebust [this message]
2004-01-12 21:37 ` NFS client write performance issue ... thoughts? Paul Smith
  -- strict thread matches above, loose matches on Subject: below --
2004-01-12 12:45 Mikkelborg, Kjetil
2004-01-12 17:30 ` Paul Smith
2004-01-08 17:32 trond.myklebust
2004-01-08 17:47 ` Paul Smith
2004-01-08 17:48 ` trond.myklebust
2004-01-07 20:50 Lever, Charles
2004-01-06 16:17 Lever, Charles
2004-01-06 18:10 ` Paul Smith
2004-01-06  4:34 Trond Myklebust
2004-01-06  6:33 ` Paul Smith
2004-01-05 22:11 Paul Smith
2004-01-08 15:26 ` Paul Smith

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=32997.141.211.133.197.1073683824.squirrel@webmail.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=nfs@lists.sourceforge.net \
    --cc=pausmith@nortelnetworks.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.