Derrick
On Feb 7, 2011, at 6:36 PM, Jeffrey Hutzelman <[email protected]> wrote: > --On Monday, February 07, 2011 02:04:46 PM -0500 Jeffrey Altman > <[email protected]> wrote: > >> In the dropbox case the client has no need to read anything from the >> server. It should only be creating new files. > > So, the thing that everyone seems to be forgetting is that the client > provides a cached view on the contents of the server, and that parts of a > file may disappear from the client's cache because the space is needed for > something else. > > The expected semantics of dropboxes are that I can open a new file and then > write and read back as much as I want until I close it. A simple file copy > won't need to read back, but some other applications might. If the file in > question is large, or there is a lot of cache pressure, the client may be > forced to write some dirty buffers and remove them from the cache even though > the file has not been closed. Clients do that depending on the fact that > they can always read the flushed chunks back from the fileserver if the > application references them again. > > > Some compromise is needed here for the anonymous case. This is the best one I can conceive. > > >> If the Unix CM is reading beyond the end of file as part of preparing a >> chunk to be written, that sounds like a bug to me. > > Who said anything about reading beyond EOF? > If you write to part of a chunk, the CM must first ensure it has an > up-to-date copy of that chunk in the cache. > Either there was cache pressure (I care) or multiple writers to a single insert (don't care). Otherwise, LocalHero... >>> The general problem, yes. But the text you are referencing treats it as >>> a security/visibility problem. The change Derrick is talking about >>> introduces a new problem where the write to the dropbox file could >>> potentially fail, making the mechanism effectively break depending on >>> the use case. >>> >>> I'm not saying that's necessarily a big problem, but it is a new thing >>> that users should be made aware of. >> >> The write will never fail. > > Unless it requires reading back a chunk first, which fails because the server > won't let you read a chunk back. > The write doesn't require it. Someone else may require it to get to the point of letting you write, but the write doesn't care. It will write. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
