Re: [PATCH 24/27] NFS: Use local caching [try #2]

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Howells <dhowells@...>
Cc: <Trond.Myklebust@...>, <nfsv4@...>, <linux-kernel@...>, <linux-security-module@...>, <selinux@...>, <linux-fsdevel@...>
Date: Thursday, January 24, 2008 - 5:22 pm

Some comments below.

This patch really ought to be broken into more manageable atomic changes 
to make it easier to review, and to provide more fine-grained 
explanation and rationalization for each specific change via individual 
patch descriptions.

David Howells wrote:

This should no longer be necessary.  The latest mount.nfs subcommand 
from nfs-utils supports text-based mounts when running on kernels 2.6.23 
and later.


I hope you intend to provide updates to nfs(5) that describe the new 
mount options you introduce in this and later patches.  You don't 
mention it, but I assume that "nofsc" is the default behavior.


Add comments like this in a separate clean up patch.


A suggestion: fs/nfs/fsc-index.c might be a better name.


It might be useful to explain here why you need to supplement the mtime, 
ctime, and size fields that already exist in an NFS inode.


Not sure why you are using the server's port here.  In almost every case 
the server side port number will be 2049, so it really doesn't add any 
uniquification.

If you're going for the client side port number, that changes after 
every connection, so it would be useless to identify a cache after a 
reboot (or even after the connection idles out!).


I strongly recommend you use the existing IPv6 address conversion macros 
for this instead of open-coding yet another way of mapping an IPv4 
address to an IPv6 address.

However, since AF_INET6 support is being introduced in the NFS client in 
2.6.24, I recommend you take a look at these source files after Trond 
has pushed his NFS_ALL for 2.6.24.


I'm going to have to study your latest fscache implementation in 
previous patches before commenting on most of the rest of this patch.


  "Get"


   [ Snipped... ]


See below: the NFS cache-related stats should be added to nfs_iostats.


Why did you choose to create a new field for this rather than setting up 
a new NFS_MNT flag?  The new in-kernel NFS mount option parser uses the 
NFS_MNT flags too.


These all belong in the nfs_iostats structure.  We don't handle 
performance metrics using atomic_t, as that results in undue overhead on 
SMP systems.  nfs_iostats is already set up with nice per-CPU vectors to 
prevent contention.

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 00/27] Permit filesystem local caching [try #2], David Howells, (Wed Jan 23, 1:20 pm)
[PATCH 24/27] NFS: Use local caching [try #2], David Howells, (Wed Jan 23, 1:22 pm)
Re: [PATCH 24/27] NFS: Use local caching [try #2], Chuck Lever, (Thu Jan 24, 5:22 pm)
Re: [PATCH 24/27] NFS: Use local caching [try #2], David Howells, (Thu Feb 7, 6:57 am)
Re: [PATCH 24/27] NFS: Use local caching [try #2], David Howells, (Tue Jan 29, 11:25 pm)
Re: [PATCH 24/27] NFS: Use local caching [try #2], Chuck Lever, (Wed Jan 30, 6:36 pm)
Re: [PATCH 24/27] NFS: Use local caching [try #2], David Howells, (Thu Jan 31, 7:29 pm)
Re: [PATCH 24/27] NFS: Use local caching [try #2], Trond Myklebust, (Wed Jan 30, 2:46 am)
Re: [PATCH 24/27] NFS: Use local caching [try #2], Trond Myklebust, (Thu Jan 24, 5:08 pm)
[PATCH 26/27] NFS: Display local caching state [try #2], David Howells, (Wed Jan 23, 1:22 pm)
[PATCH 23/27] NFS: Fix memory leak [try #2], David Howells, (Wed Jan 23, 1:22 pm)
Re: [PATCH 23/27] NFS: Fix memory leak [try #2], Trond Myklebust, (Thu Jan 24, 5:15 pm)