> On Nov 23, 2015, at 1:56 PM, Matthew Ahrens <[email protected]> wrote: > > That seems like it would work and would be pretty conservative. It wouldn't > help if the filesystem already existed and had the refquota set. It could > also leave you in a strange state, where you have a filesystem that > references more than what the send stream says is the refquota, and the > refquota is not set (if it fails, or if you crash right before it fails?).
I didn't think about receiving into an existing filesystem. I'll spend more time on that case in a future note. > Note that there is no command to resume a "zfs send -R/-p/-I", so you > wouldn't break resuming. You can resume individual streams, or you can redo > the "zfs send -R", which will send the properties again. Phew. I was worried about resuming, so I'm glad -R doesn't have a resume-send case. > I wonder if a better semantic would be: if you specify a new flag > (--allow-overquota?) to zfs receive, we set the quota/refquota as normal, but > we disable enforcement of it while doing the receives. When the receive > completes, enforcement would be re-enabled, and you might be over > quota/refquota. (The disablement would not be stored on disk, so if you > crash the quota would again be enforced.) I'm playing with a prototype where I lifted the checks into the zfs_ioctl.c function zfs_ioc_recv() instead. I'm about to reboot an ONUed system to try it. I'll report back with details (and if things go well with the bug-reported case, I'll see about some existing-filesystem tests as well). Thanks, Dan _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
