[EMAIL PROTECTED] wrote on 03/21/2007 11:00:43 AM: > > >The problem is that in order to restrict disk usage, ZFS *requires* > >that you create this many filesystems. I think most in this situation > >would prefer not to have to do that. The two solutions I see would > >be to add user quotas to ZFS or to be able to set a quota on a > >directory without it becoming it's own filesystem. > > What this really means is that ZFS filesystems need to be as > expensive as UFS quotas and not (considerably) more. Well... and apply to user/groups restriction workflows not just child node total sizes. Many times you can create a bunch o zfs mounts to limit usage or reservations, but at some level this is not as flexible as user/group level restrictions in many workflows (or even possible given some structures and workflows). For instance how would you limit John and Sarah in accounting from gobbling up all the space in the accounting group's folder while allowing the managers Mike and Amy to do so without changing their file structure to match the restrictions instead of their workflow. User quotas have their place and are very well suited for certain tasks, zfs quota's and reservations are more focused on protecting pooled storage from overuse/constraint. Building out a ton of fs mounts to try to work around missing user quotas does not scale well in any terms -- system cost, admin cost or artificial filesystem layout/restructuring. The cost (cpu/memory) of zfs mountpoints is one concern not by any means the only or core concern. > > As it stands now, ZFS filesystems have two serious limitations: > - they cost 100Ks per fs (when mounted) > - they are, by default, all mounted all the time > > >Any chance that user quotas will be added in the future? It would go > >a long way to alleviating this problem. Ideally, snapshots would not > >count against user quotas if possible. > > If snapshots don't count against quota, then you give users an > easy way to extend their quotas by (number of snapshots) fold. I see the point and agree to some extent, and will add that when quotas are putback and do take into account snap bit hogging, administrators will _need_ way better snap space usage reporting tools. I think many workflows may not want to force users to "own" the snap hog space -- in such a case as a home directory where administrators set the snap rotation and the users have no control as to when or how the snaps will be released. This space accounting (live + snap vs live) should be a setting. -Wade _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
