it would involve a semantic change but we could start flushing changes in the background before fsync. there are of course potential issues.
On 9/24/07, Russ Allbery <[EMAIL PROTECTED]> wrote: > > Adam Megacz <[EMAIL PROTECTED]> writes: > > > I've noticed that when writing really large files with something like > > "cat .. | gzip > /afs/file" on a machine with a very large cache manager > > cache, several hundred megabytes of data can accumulate locally before > > being written back when close() is called. In some cases, this can lead > > to write() calls being quite fast, but the final close() call takes an > > hour or more to return. We (hcoop) would like to avoid this situation > > if possible. > > > I assume that this amount of "unwritten" data cannot exceed the size of > > the cache -- and I guess if this happens, the application is blocked > > until enough StoreData's have happened to free up cache space. Is there > > any way to get the CM to start this throttling earlier on? Say, for > > example, when the amount of unwritten data reaches 50MB? Unfortunately > > setting the cache size to 50MB is not an option -- this machine performs > > other tasks as well. > > Can you convince your application to call fsync periodically? If so, > that's the fastest and easiest solution. fsync will write the data back > to the server. > > -- > Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info >
