[OpenAFS] Re: [OpenAFS-devel] OpenAFS callbacks

[Matt W. Benjamin]

Hi,

It would be helpful to better understand the original design intention here.  Not knowing the semantic intent of whatever remote update has taken place, the cm cannot reliably decide what is a compatible update.  Assuming that no remote change is compatible with any local change contradicts, at least, extended callbacks StoreData assumptions.  Nb., cache bypass semantics and direct io (yfs) already affect this behavior for those respective special cases, iiuc.

Matt

----- "Simon Wilkinson" <sxw@inf.ed.ac.uk> wrote:

> On 11 Apr 2011, at 20:47, Russ Allbery wrote:
> 
> > Simon Wilkinson <sxw@inf.ed.ac.uk> writes:
> > 
> >> There is one exception to this behaviour on Unix. If you have
> opened a
> >> file for writing, and dirtied that file, then the version of the
> data on
> >> your client remains that at the point the file was dirtied - any
> >> subsequent changes on the fileserver won't be delivered to your
> client
> >> until you close the open file handle (and the data is sent to the
> >> server)
> > 
> > Or when you call fflush, no?
> 
> The code here is pretty gnarly, but yeah - calling fsync should clear
> the IFDataMod flag which stops us from getting new data from the
> server, and so result in you seeing new data, providing you don't
> write anything else to the file.
> 
> Cheers,
> 
> Simon.
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309