As it turns out, I'm working on zfs user quotas presently, and expect to integrate in about a month. My implementation is in-kernel, integrated with the rest of ZFS, and does not have the drawbacks you mention below.

I merely suggested "my design" as it may have been something I _could_ have implemented, as it required little ZFS knowledge. (Adding hooks is "usually" easier). But naturally that has already been shown not to be the case.

A proper implementation is always going to be much more desirable :)




Good, that's the behavior that user quotas will have -- delayed enforcement.

There probably are situations where precision is required, or perhaps historical reasons, but for us a delayed enforcement may even be better.

Perhaps it would be better for the delivery of an email message that goes over the quota, to be allowed to complete writing the entire message. Than it is to abort a write() call somewhere in the middle, and return failures all the way back to generating a bounce message. Maybe.. can't say I have thought about it.



My implementation does not have this drawback. Note that you would need to use the recovery mechanism in the case of a system crash / power loss as well. Adding potentially hours to the crash recovery time is not acceptable.

Great! Will there be any particular limits on how many uids, or size of uids in your implementation? UFS generally does not, but I did note that if uid go over 10000000 it "flips out" and changes the quotas file to 128GB in size.


Not to mention that this information needs to get stored somewhere, and dealt with when you zfs send the fs to another system.

That is a good point, I had not even planned to support quotas for ZFS send, but consider a rescan to be the answer. We don't ZFS send very often as it is far too slow.

Lund

--
Jorgen Lundman       | <lund...@lundman.net>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to