linux-kernel - Re: [PATCH 05/19] NFS: Use local caching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <455B0A58.9080303@RedHat.com>
Date:	Wed, 15 Nov 2006 07:38:48 -0500
From:	Steve Dickson <SteveD@...hat.com>
To:	David Howells <dhowells@...hat.com>
CC:	torvalds@...l.org, akpm@...l.org, sds@...ho.nsa.gov,
	trond.myklebust@....uio.no, selinux@...ho.nsa.gov,
	linux-kernel@...r.kernel.org, aviro@...hat.com
Subject: Re: [PATCH 05/19] NFS: Use local caching

David Howells wrote:
> The attached patch makes it possible for the NFS filesystem to make use of the
> network filesystem local caching service (FS-Cache).
> 
> To be able to use this, an updated mount program is required.  This can be
> obtained from:
> 
> 	http://people.redhat.com/steved/cachefs/util-linux/
> 
> To mount an NFS filesystem to use caching, add an "fsc" option to the mount:
> 
> 	mount warthog:/ /a -o fsc
Note: the nfs mounting code has recently moved from util-linux
into nfs-utils but the functionality is off by default (hopefully that
will change soon). In Fedora Core 6 we've decided to go ahead and
turn on the mount code which in turned allowed us to added
the '-o fsc' mounting flag. So with FC6, there is no need
to download a modified util-linux.

> +static inline void nfs_fscache_get_fh_cookie(struct inode *inode, int aycache) {}
> +static inline void nfs_fscache_release_fh_cookie(struct inode *inode) {}
> +static inline void nfs_fscache_zap_fh_cookie(struct inode *inode) {}
> +static inline void nfs_fscache_renew_fh_cookie(struct inode *inode) {}
> +static inline void nfs_fscache_disable_fh_cookie(struct inode *inode) {}

To create a cleaner and more scalable "cookie" interface into NFS,
I suggest that we remove the type of cookie from the name of the
cookie routines (meaning remove the _fh_ from the names) and bury
that type of information in the actual cookie routines. The last
thing the NFS code should care about is the type of cookie it needs
to use.. those decisions should exist in the cookie routines, not
in the mainline code... imho...

So resulting in routines would like:

static inline void nfs_fscache_get_cookie(struct inode *inode) {}
static inline void nfs_fscache_release_cookie(struct inode *inode) {}
static inline void nfs_fscache_zap_cookie(struct inode *inode) {}
static inline void nfs_fscache_renew_cookie(struct inode *inode) {}
static inline void nfs_fscache_disable_cookie(struct inode *inode) {}

Then instead of just having a fscache_cookie hang off the NFS inode,
have a pointer to a nfs_fscache_cookie structure:

struct nfs_fscache_cookie {
     int   type;   /* the type cookie: FILE, READDIR, XATTR, etc */
     ulong flags;  /* Doesn't all interfaces need flags :-) */
     void *cookie; /* the actual cookie */
};

Using an interface like this, would allow all the ugly cookie processing
to stay far away from the mainline NFS code, also makes the interface
into NFS much cleaner, simpler and scalable. Finally all changes (i.e. 
adding another cookie type) would be isolated away from the mainline
code and confined to a couple files.

Comments?

steved.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/