[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29130.1277891246@redhat.com>
Date: Wed, 30 Jun 2010 10:47:26 +0100
From: David Howells <dhowells@...hat.com>
To: Andreas Dilger <adilger@...ger.ca>
Cc: dhowells@...hat.com, Trond Myklebust <trond.myklebust@....uio.no>,
viro@...IV.linux.org.uk, smfrench@...il.com, jlayton@...hat.com,
mcao@...ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, samba-technical@...ts.samba.org,
sjayaraman@...e.de, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/3] Add a pair of system calls to make extended file stats available [ver #2]
Andreas Dilger <adilger@...ger.ca> wrote:
> > Yes, but could we please also add a flag that allows you to specify that
> > the kernel _must_ provide up to date attributes.
>
> To my reading, if the query_flags are set in the input buffer, then the
> attributes MUST be fetched. If they are unset, then they MAY be fetched,
> and the corresponding query_flags will be set in the return buffer. If the
> query_flags are not set in the return buffer then I assume the output values
> are undefined.
I think Trond may have a point, looking at nfs_getattr().
There can be three levels:
(1) Don't check with the server, just go with what we've got in the cache if
it's available. Results returned may be approximate.
(2) Check with the server if the cached attributes are out of date or if
something is requested that we don't keep in RAM.
(3) Check with the server anyway.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists