<div dir="ltr">Someone sent me a link to this:<div><a href="http://arxiv.org/pdf/1505.02656v1.pdf">http://arxiv.org/pdf/1505.02656v1.pdf</a></div><div>Very cool. We'll need to start using that.</div><div><br></div><div>This reminded me to send my changelog/robinhood/HSM concerns that I brought up at LUG to you guys for your thoughts.</div><div><br></div><div>1. What should happen when the changelog on an MDS fills up? Maybe LCAP helps with the processing rate, but fundamentally the issue might still happen if nobody consumes due to various software or comms errors. We should either stop recording records and risk losing change tracking, or stop MDS processing. (I believe at the moment this will just crash the MDS.) We probably need a high water mark.</div><div><br></div><div>2. There should be some kind of rate limiting for HSM requests (RH to MDS), so that the number of HSM requests queued up in the coordinator doesn't grow without bound.  Probably we need a -EAGAIN return code to RH at some point.</div><div><br></div><div>3. It feels like there needs to be some feedback from the backend HSM storage to RH, in particular to pass back a "backend full" message. We can presumably pass a backend ENOSPC from the copytool back to the Coordinator, but how can that message get back to Robinhood? I guess coordinator could start returning ENOSPC for subsequent archive requests from RH, but then we have to clear that response if the backend condition clears.</div><div><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><b>--</b><div><font size="1"><b>Nathan Rutman · <font color="#666666">Principal Systems Architect</font><br><font color="#0b5394">Seagate Technology</font></b><b> · </b>+1 503 877-9507<b> · </b>GMT-8</font></div></div></div></div></div></div>
</div></div>