Hi Matt, On Nov 23, 2010, at 16:14 , Matt W. Benjamin wrote:
> 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... as an AFS user, I never expected a guarantee that no data is actually written out to the fileserver ever before the file is closed on the client. After all, I'd like to be able to write files larger than the cache without having to close and reopen them in append mode. But it's a huge advantage of AFS over other filesystems that this is the usual case for files of modest size compared to the cache, because it helps avoiding fragmentation on the fileserver. Imagine 1500 batch jobs on 200 clients dribbling into 3000 files in the same volume: I don't think that today's typical backend filesystems to the namei fileserver will be able to limit fragmentation as much as in the write-on-close case. But as long as data is flushed in consecutive chunks as large as possible (or at least reasonably large if possible), it's perfectly ok to do it before the file is closed at least for our use case. - Stephan > > Matt > >> >> 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. >> >> Cheers, >> >> Simon. -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany
smime.p7s
Description: S/MIME cryptographic signature
