On Mon, Jan 18, 2016 at 8:25 AM, Dan McDonald <[email protected]> wrote:
> https://www.illumos.org/issues/6562 > > While I have the fix for my customer's incremental case in hand, the more > general case question lingers. Currently, one can do: > > zfs create rpool/foo > zfs set refquota=10M rpool/foo > yes > /rpool/foo/fill-er-up > zfs snapshot rpool/foo@1 > zfs send -R rpool/foo@1 | zfs recv rpool/bar > > and while rpool/bar gets created, the refquota property IS NOT INCLUDED. > > Since refquota's weird anyway, and part of the post-4986 "delayed > properties", one COULD special-case this some more, to figure out how to > set the refquota without failing because of the one-transaction overage > discussed in earlier thread. > > My question to the community is this: > > Should I bother fixing the create-new-filesystem case for refquota? > Correct behavior would be for the receive to work and set the refquota (and quota for that matter) even if it puts you into an over-[ref]quota situation. Your changes make the situation better although not fixed in all cases. I'm fine with taking your changes as-is and fixing the rest of the problem later. As for how to fix it completely, I think it would be reasonable to allow the [ref]quota to be set to less than the current space referenced/used. That said, if we want to preserve the current behavior of "zfs set" failing in this case, we could move the check from the kernel to libzfs, so that "zfs set" fails but "zfs receive" can successfully set the [ref]quota. Or we could allow "zfs set" to set the [ref]quota as well, and print a warning, like "Note: refquota set to X MB which is less than the current referenced (Y MB). Affected datasets will be readonly except for deletions." --matt > > 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
