On Tue, Jan 5, 2016 at 8:06 AM, Dan McDonald <[email protected]> wrote:
> After updating OmniOS with the fix for illumos 4986 (refquota-on-receive > is not treated properly), my customer indicates that their bug is not fixed. > > They were kind enough to supply me with a new reproduction, involving > incremental streams. What I found this time might not be a receive-side > problem, but instead may be a space accounting problem. I've attached the > (verbose) shell script to reproduce the problem, and will annotate its > output in this email. > > > # ./new-repro.sh > > + zfs destroy -R rpool/foo > > cannot open 'rpool/foo': dataset does not exist > > + zfs destroy -R rpool/bar > > cannot open 'rpool/bar': dataset does not exist > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > Okay, so let's make sure we've cleared out the test datasets for this > problem. > > > + zfs create rpool/foo > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/foo 19456 26712966144 19456 /rpool/foo > > The new filesystem is already using 19456 bytes. Probably for directories > and what-not, that's fine. > > > + zfs set refquota=150M rpool/foo > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/foo 19456 157266944 19456 /rpool/foo > > Now 150M == 150 * 1024 * 1024 == 157286400. 157286400 - 19456 == > 157266944. So far so good! > > > + zfs snapshot rpool/foo@1 > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/foo 19456 157266944 19456 /rpool/foo > > rpool/foo@1 0 - 19456 - > > And the snapshot costs nothing in "USED". Also sensible. > > > + zfs recv rpool/bar > > + zfs send -R rpool/foo@1 > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/bar 19456 157266944 19456 /rpool/bar > > rpool/bar@1 0 - 19456 - > > rpool/foo 19456 157266944 19456 /rpool/foo > > rpool/foo@1 0 - 19456 - > > And so far, the newly-received copy seems to also jive with its origin AND > reality. This is great! > > > + yes test > > + 1> /rpool/foo/fillerup > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/bar 19456 157266944 19456 /rpool/bar > > rpool/bar@1 0 - 19456 - > > rpool/foo 157347840 0 157338624 /rpool/foo > > rpool/foo@1 9216 - 19456 - > > WHOA! Okay, now we start to see a crack. While "bar" is nice and real, > "foo" looks... off. > > We're using 157347840, and worse, referring to 157338624. This is 52224 > bytes larger than the 157286400 bytes that is the refquota. What gives? > To ensure that you can use your entire refquota (or quota), we allow one transaction to exceed the available space. So it is possible to be over quota by a small amount. All of the behavior described here makes sense to me, however the interaction with receiving property settings is not very helpful. 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). --matt > > This won't receive properly, will it? > > > + zfs snapshot rpool/foo@2 > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/bar 19456 157266944 19456 /rpool/bar > > rpool/bar@1 0 - 19456 - > > rpool/foo 157347840 0 157338624 /rpool/foo > > rpool/foo@1 9216 - 19456 - > > rpool/foo@2 0 - 157338624 - > > Well, the snapshot jives with "foo"'s new reality, at least... > > > + zfs recv -F rpool/bar > > + zfs send -I 1 -R rpool/foo@2 > > cannot receive incremental stream: destination rpool/bar space quota > exceeded > > BOOM! Can't receive the stream because 157338624 is greater than > 157266944. It's 71680 greater, in fact. > > > + egrep 'foo|bar|NAME' > > + zfs list -pt all > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/bar 19456 157266944 19456 /rpool/bar > > rpool/bar@1 0 - 19456 - > > rpool/foo 157347840 0 157338624 /rpool/foo > > rpool/foo@1 9216 - 19456 - > > rpool/foo@2 0 - 157338624 - > > # > > > Is there anything I'm missing? Clues, as always, are welcome. > > I'm also going to include a zstreamdump(1M) of "zfs send -I 1 -R > rpool/foo@2". > > Thanks, > Dan > > > > > > > ------------------------------------------- > illumos-zfs > Archives: https://www.listbox.com/member/archive/182191/=now > RSS Feed: > https://www.listbox.com/member/archive/rss/182191/27179292-bb9021e0 > Modify Your Subscription: > https://www.listbox.com/member/?member_id=27179292&id_secret=27179292-acf9db97 > Powered by Listbox: http://www.listbox.com > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
