> OK, you asked for "creative" workarounds... here's one (though it requires > that the filesystem be briefly unmounted, which may be deal-killing):
That is, indeed, creative. :) And yes, the unmount make it impractical in my environment. I ended up going back to rsync, because we had more and more complaints as the snapshots accumulated, but am now just rsyncing to another system, which in turn runs snapshots on the backup copy. It's still time- and i/o-consuming, and the users can't recover their own files, but at least I'm not eating up 200% of the space otherwise necessary on the expensive new hardware raid and fielding daily over-quota (when not really over-quota) complaints. Thanks for the suggestion. Looking forward to the new feature... BP > > zfs create pool/realfs > zfs set quota=1g pool/realfs > > again: > zfs umount pool/realfs > zfs rename pool/realfs pool/oldfs > zfs snapshot pool/[EMAIL PROTECTED] > zfs clone pool/[EMAIL PROTECTED] pool/realfs > zfs set quota=1g pool/realfs (6364688 would be useful here) > zfs set quota=none pool/oldfs > zfs promote pool/oldfs > zfs destroy pool/backupfs > zfs rename pool/oldfs pool/backupfs > backup pool/[EMAIL PROTECTED] > sleep $backupinterval > goto again > > FYI, we are working on "fs-only" quotas. > > --matt -- [EMAIL PROTECTED] _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
