Kyle McDonald wrote: > Richard L. Hamilton wrote: > >> I think sharemgr was created to speed up the case of sharing out very >> high numbers of filesystems on NFS servers, which otherwise took >> quite a long time. >> >> That's not to say that there might not be other problems with scaling to >> thousands of filesystems. But you're certainly not the first one to test it. >> >> For cases where a single filesystem must contain files owned by >> multiple users (/var/mail being one example), old fashioned >> UFS quotas still solve the problem where the alternative approach >> with ZFS doesn't. >> >> >> > This seems to come up over and over, and while I haven't had a need to > implement it yet I probably will eventually. > I don't like the 1ZFS/User idea either, and I've just been thinking that > user/group quotas would eventually be available, probably before I > needed them. > > But even with the demand shown by these posts, I don't see mention of > anyone working on this. > > Is there some technical difference with ZFS that makes a normal > user/group quota impossible? > Or is there a general feeling that it's an icky idea and (for some > reason?) something to be avoided at all costs? > Or is it on the list of things to add, and we just haven't made it to it > yet? > > I'm ok with the last option. It's the first 2 that I don't like. :) It > just seems that a lot of effort has gone into making performance > improvements, and new utilities like the 'sharemgr' that Richard > mentions, all to work around the lack of user/group quotas?? It's > starting to look like it might have just been easier to implement the > quotas from the beginning. > > -Kyle
One thing I think we should seriously consider is rather than just demanding 'we want quotas' (and, I'd like them too), is think about what we want. Good old UFS quotas had some _major_ drawbacks, and I don't think we just want that re-implemented. Quotas are great when, for administrative purposes, you want a large number of users on a single filesystem, but to restrict the amount of space for each. The primary place I can think of this being useful is /var/mail , or for users creating large block files (say each user needs a DB back-end file). The ZFS filesystem approach is actually better than quotas for User and Shared directories, since the purpose is to limit the amount of space taken up *under that directory tree*. Quotas do a miserable job with Shared directories, and get damned confusing if there is the ability of anyone else to write to your User directory (or vice versa). Remember, that quotas aren't free, and while we have seen some performance problems with the '10,000 ZFS filesystems' approach, there are performance issues to be had when trying to keep track of 10,000 user quotas on a file system, as well. I can't say they are equal, but don't think that quotas are just there for the implementing. There's a penalty for them, too. As far as implementing quotas go, I can't say how hard it is. But, here's a least something to think about: where do we count? At the Pool level? At the filesystem level? What about nested filesystems? How hard does it get to count (and manage) nested quotas? For instance, if I have a nested ZFS filesystem setup, and assuming a simple restriction that the quota on any nested filesystem can be equal to or less than its parent, what about this example: filesystem quota foo 10 mb foo/bar 6 mb foo/bar/baz 6 mb foo/quux 6mb how do I easily report these quotas (i.e. can I even see all the filesystems)? how confusing is it if I have 6MB in foo/bar/baz, and then can't put more than 4mb in foo/quux? Does "quota foo" report all the nested quotas, also? Should "quota foo/bar/baz" also include the quotas of its parents (i.e. foo and foo/bar )? -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
