2007-11-17 00:11:35

by Timo Sirainen

[permalink] [raw]
Subject: Cache flushing

Solaris and BSDs support flushing attribute cache safely using
fchown(fd, (uid_t)-1, (gid_t)-1). Could Linux be changed to support this
as well? If I'm looking at the sources right, this might work
(completely untested):

--- inode.c.old 2007-11-16 22:18:46.000000000 +0200
+++ inode.c 2007-11-16 22:19:44.000000000 +0200
@@ -322,6 +322,7 @@
nfs_setattr(struct dentry *dentry, struct iattr *attr)
{
struct inode *inode = dentry->d_inode;
+ struct nfs_inode *nfsi = NFS_I(inode);
struct nfs_fattr fattr;
int error;

@@ -334,8 +335,10 @@

/* Optimization: if the end result is no change, don't RPC */
attr->ia_valid &= NFS_VALID_ATTRS;
- if (attr->ia_valid == 0)
+ if (attr->ia_valid == 0) {
+ nfsi->cache_validity |= NFS_INO_INVALID_ATTR;
return 0;
+ }

lock_kernel();
nfs_begin_data_update(inode);

Another problem I have is that it's difficult to get a file's data cache
flushed. The only way I found was to successfully fcntl() lock the file.
This is pretty bad from performance point of view since often I don't
want/need to lock the file.

Solaris and BSDs invalidate also a file's data cache when its attribute
cache is invalidated. It would be nicer if there was a separate way, but
I'd settle for fchown(fd, (uid_t)-1, (gid_t)-1) invalidating data cache
as well.

Actually I did also look at posix_fadvise(fd, 0, 0,
POSIX_FADVN_DONTNEED). It appears to work, but I'm a bit worried about
race conditions that causes pages to randomly not get dropped because
invalidate_mapping_pages() doesn't drop locked pages.


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part
(No filename) (228.00 B)
(No filename) (362.00 B)
Download all attachments

2007-11-17 19:46:36

by Trond Myklebust

[permalink] [raw]
Subject: Re: [NFS] Cache flushing


On Sat, 2007-11-17 at 02:11 +0200, Timo Sirainen wrote:
> Solaris and BSDs support flushing attribute cache safely using
> fchown(fd, (uid_t)-1, (gid_t)-1). Could Linux be changed to support this
> as well? If I'm looking at the sources right, this might work
> (completely untested):
>
> --- inode.c.old 2007-11-16 22:18:46.000000000 +0200
> +++ inode.c 2007-11-16 22:19:44.000000000 +0200
> @@ -322,6 +322,7 @@
> nfs_setattr(struct dentry *dentry, struct iattr *attr)
> {
> struct inode *inode = dentry->d_inode;
> + struct nfs_inode *nfsi = NFS_I(inode);
> struct nfs_fattr fattr;
> int error;
>
> @@ -334,8 +335,10 @@
>
> /* Optimization: if the end result is no change, don't RPC */
> attr->ia_valid &= NFS_VALID_ATTRS;
> - if (attr->ia_valid == 0)
> + if (attr->ia_valid == 0) {
> + nfsi->cache_validity |= NFS_INO_INVALID_ATTR;
> return 0;
> + }
>
> lock_kernel();
> nfs_begin_data_update(inode);

Why is this needed?

> Another problem I have is that it's difficult to get a file's data cache
> flushed. The only way I found was to successfully fcntl() lock the file.
> This is pretty bad from performance point of view since often I don't
> want/need to lock the file.
>
> Solaris and BSDs invalidate also a file's data cache when its attribute
> cache is invalidated. It would be nicer if there was a separate way, but
> I'd settle for fchown(fd, (uid_t)-1, (gid_t)-1) invalidating data cache
> as well.
>
> Actually I did also look at posix_fadvise(fd, 0, 0,
> POSIX_FADVN_DONTNEED). It appears to work, but I'm a bit worried about
> race conditions that causes pages to randomly not get dropped because
> invalidate_mapping_pages() doesn't drop locked pages.

Again, why do you need this level of data cache invalidation? If you
don't want cached i/o, then use O_DIRECT.

Trond


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs