[OpenAFS] limit amount of uncommitted cache manager data?
Derrick Brashear
shadow@gmail.com
Mon, 24 Sep 2007 14:46:22 -0400
------=_Part_3906_17262926.1190659582978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 <rra@stanford.edu> wrote:
>
> Adam Megacz <megacz@cs.berkeley.edu> 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 (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
------=_Part_3906_17262926.1190659582978
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
it would involve a semantic change but we could start flushing changes in the background before fsync. there are of course potential issues.<br><br><div><span class="gmail_quote">On 9/24/07, <b class="gmail_sendername">Russ Allbery
</b> <<a href="mailto:rra@stanford.edu">rra@stanford.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Adam Megacz <
<a href="mailto:megacz@cs.berkeley.edu">megacz@cs.berkeley.edu</a>> writes:<br><br>> I've noticed that when writing really large files with something like<br>> "cat .. | gzip > /afs/file" on a machine with a very large cache manager
<br>> cache, several hundred megabytes of data can accumulate locally before<br>> being written back when close() is called. In some cases, this can lead<br>> to write() calls being quite fast, but the final close() call takes an
<br>> hour or more to return. We (hcoop) would like to avoid this situation<br>> if possible.<br><br>> I assume that this amount of "unwritten" data cannot exceed the size of<br>> the cache -- and I guess if this happens, the application is blocked
<br>> until enough StoreData's have happened to free up cache space. Is there<br>> any way to get the CM to start this throttling earlier on? Say, for<br>> example, when the amount of unwritten data reaches 50MB? Unfortunately
<br>> setting the cache size to 50MB is not an option -- this machine performs<br>> other tasks as well.<br><br>Can you convince your application to call fsync periodically? If so,<br>that's the fastest and easiest solution. fsync will write the data back
<br>to the server.<br><br>--<br>Russ Allbery (<a href="mailto:rra@stanford.edu">rra@stanford.edu</a>) <<a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a>><br>_______________________________________________
<br>OpenAFS-info mailing list<br><a href="mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br><a href="https://lists.openafs.org/mailman/listinfo/openafs-info">https://lists.openafs.org/mailman/listinfo/openafs-info
</a><br></blockquote></div><br>
------=_Part_3906_17262926.1190659582978--