[OpenAFS-devel] Potential write-consistency race

[Derrick J Brashear]

Since I'm not parsing the dates usefully, did you propose this before or
after:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.0/1417.html

Anyhow,

On Fri, 4 Oct 2002, David Howells wrote:

> In discussing the relative merits of Coda and AFS, I have come across a race
> in AFS between writes (you may or may not be aware of it).

I think it's an infrequently asked question but one which you can probably
find in info-afs archives, for instance.

> Furthermore, a similar problem occurs if the client tries to "append" to a
> file. The point at which it appends may no longer be the end of the file.

You mean client in this case as "user of the filesystem" and not "the part
that talks to the server" correct?

> What I propose, though it may not be possible to implement for standardisation
> reasons, is two additional afsint.xg operations:

IBM probably won't do it. Also, it would be hard to work AppendData into
our client without doing something like bypassing the cache on the write
and then fetching the data on callback, so client-side at least we
probably wouldn't do it, at least not soon.

> 	InsertData(
> 	  IN  AFSFid *Fid, 
> 	  AFSStoreStatus *InStatus, 
> 	  afs_int32 Pos, 
> 	  afs_int32 Length, 
> 	  OUT AFSFetchStatus *OutStatus, 
> 	  AFSVolSync *Sync
> 	) split = ?;
> 
> Which would insert data at the given position in the file without any explicit
> reference to the new EOF position. The file would be extended automatically if
> the new data overlapped the old EOF position.

so basically you want a way to bypass potential truncation, correct?

> And also:
> 
> 	AppendData(
[]

> I think these should be very easy to add to the fileservers (they just have to
> overload the StoreData() operatiosn), and a little harder to add to the
> client.

Server-wise, I think I agree. Client, see above.

Realize, though, that unless you're going forward with the "push writes as
fast as you can" theory this happens not particularly frequently, and I
think Jan has explained well why at least at this point the world isn't
ready for that. 

I should also mention that perhaps linux-kernel isn't the best place to
discuss AFS3 protocol. The best place, sadly, hasn't been well-advertised
or particularly active. That would be afs3-protocol@stacken.kth.se
(subscribe by mailing afs3-protocol-request@stacken.kth.se).

I may have missed a reply, but I should also note that OpenAFS doesn't 
have any krb5 code in the kernel, nor real krb4; Since I know one of the
messages on linux-kernel implied or stated we did, I thought I should
point that out.