[OpenAFS] Re: bonnie++ on OpenAFS

[Derek Atkins]

Hi,

"Matt W. Benjamin" <matt@linuxbox.com> writes:

> Hi,
>
> Is "write-on-close" was an expectation which could be broken?  It is
> the case that AFS has strongly expressed that its semantics are (in
> general) _sync-on-close_, and it's meaning is that an application
> which has closed an AFS file may consider any writes it made to be
> stable, and visible to other clients.  Write stability is not assured
> only on close, an application may explicitly sync when convenient.
> I'm not sure, first, how a client can ever have been assured that its
> writes were not stabilised before it closed its corresponding file(s),
> nor, how it would benefit from this?  For example, the client may not
> revoke its own operations on the file prior to closing it.  Which is
> to say, I think the CM is free to stabilise ordinary writes when any
> convenient opportunity arises.  Feel free to flame now...

My personal feeling is that the write-on-close semantic is only a
guarantee to the writing client in terms of "you can only be guaranteed
that your writes will be flushed when the file is closed".  However I do
not believe that there are any semantic rules prohibiting writes back to
the server PRIOR to closing the file.

One potential reason to delay writes to the server is that the client
may over-write dirty blocks multiple times, so you don't want to
necessarily push writes to the server at every write() operation.
However I don't see any reason that we can't flush dirty chunks back in
this situation.

> Simon says:
>
>> The problem is that we don't make good decisions when we decide to  
>> flush the cache. However, any change to flush items which are less  
>> active will be a behaviour change - in particular, on a multi-user  
>> system it would mean that one user could break write-on-close for  
>> other users simply by filling the cache.

I'd rather that write-on-close be "broken" (not that I see this as a
problem) than the cache thrashing.  Again, my feeling is that
write-on-close isn't a guarantee that your data will NOT be written
before you close(), but rather it's a guarantee that you cannot be
assured that your data is written before you close().  Semantically
these are two very distinct rules.

Pre-flushing writes ahead of the close do NOT violate this second
assurance.

Just my $0.02.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available