On Wed, Jan 6, 2016 at 2:52 PM, Dan McDonald <dan...@omniti.com> wrote:
> > > On Jan 6, 2016, at 3:54 PM, Matthew Ahrens <mahr...@delphix.com> wrote: > > > > Another solution to 4986, which would also cover the situation you're > in, would be to disable the quota/refquota while receiving, and then allow > the receive to set the quota/refquota to less than is used/referred > (putting you in an over-quota situation). > > Should one limit the overage on receive to no larger than the size of one > transaction? (I can imagine some grinning weirdo constructing a fuzz test > that would very much exceed a quota if left completely unchecked.) > > I'll dig into this and come up with something in line with your > disable-then-enable, but I'm inclined to keep the allowable overage to > whatever one transaction's worth is. And if a transaction doesn't have a > limit because it encapsulates multiple writes (which occurs to me as I > write this), I'll have to find a suitable alternative overage limit, or > decide that I should Just Trust (TM) the send stream (which I really DON'T > want to do for security/integrity reasons). > You should be able to limit it to DMU_MAX_ACCESS * spa_asize_inflation. Which is pretty large but in most cases you can assume spa_asize_inflation of no more than 2. Note that you may not want to literally disable-then-enable (e.g. what happens if you crash in the middle). Instead you could not enforce the quotas (or only enforce at quota + DMU_MAX_ACCESS * 2) while doing a receive. --matt
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
