On Wed, Oct 19, 2011 at 09:08:24PM +0200, Alan Barrett wrote: > >1. A file system type can have or not have support for quotas. If > >there is no support for quotas, nothing else works. > > > >2. Any given filesystem volume may have or not have quota data on it. > >This is the filesystem code's problem and irrelevant to the > >FS-independent logic. > > > >3. Any given filesystem volume may be mounted with or without quotas > >enabled. If quotas are not enabled, quota information is not available > >and the quota utilities will not be able to do anything. > > > >4. Once mounted, quotas can be either on or off. As far as the > >FS-independent code is concerned, quotas being off means only that > >they aren't enforced; that is, with quotas off operations that > >increase usage do not fail with EDQUOT. When quotas are off, quota > >information can still be inspected or updated. > > I don't like the names "on" and "off" at level 4. They are too vague, > and too easily confused with "enabled" or "not enabled" at level 3. > > I'd suggest these names: > > 1. "supported" or "not supported" by the file system format > 2. "present" or "not present" in the file system backing store > 3. "enabled" or "not enabled" in the mounted file system > 4. "enforced" or "not enforced" for the system/user/group/file system/???
quotaon(8) already exists and I don't think renaming it is a good idea. That more or less fixes the terminology "on" and "off" in place. However, we can try to think up some other less confusing wording for (3). > I think you might want a fs-independent API to ask the file system > whether or not quotas are supported or present. The intent was that you try quota_open() and if it fails, check the errno, something like EOPNOTSUPP for no support, maybe ENOENT for no quota data, something else if not enabled at mount time. There's already some precedent for this in some of the existing code. (I guess I didn't actually mention this...) -- David A. Holland dholl...@netbsd.org
