On Fri, Oct 21, 2011 at 08:25:44AM +0000, David Holland wrote:
> On Wed, Oct 19, 2011 at 06:09:27PM +0000, David Holland wrote:
> > So, a few months back we got a new improved quota format for FFS.
> > [...]
>
> All right, I give up.
ok, I have been asked by Important People(TM) to resurrect this and
not just let it all go. So, bring out your flamethrowers...
The new discovery that struct ufs_quota_entry is meant to be
fs-independent changes the complexion of things quite a bit.
Apparently we do more or less have a filesystem-independent quota
interface; however, there is still potentially a lot of cleanup to do,
some of which should get done before branching -6 if it's going to get
done at all.
ISTM that there are four more or less separable issues now:
1. Fix the name of struct ufs_quota_entry and any related things to
make it clear that they're fs-independent. This is not optional.
2. Clean up the userlevel quota tools and libquota along the lines
I previously proposed, giving libquota a clear API and
centralizing all the legacy userlevel quota code.
3. Abolish the proplib-based transport encoding. Since it turns out
that the use of proplib for quotactl(2) is only to encode struct
ufs_quota_entry for transport across the user/kernel boundary,
converting it back on the other side, it seems to me that it's
a completely pointless complication and a poor use of proplib.
It's also messy, even compared to other proplib usage elsewhere.
(Regarding claims of easier/better compatibility, see below.)
4. Abolish the xmlrpc-type user interface of quotactl(8) in favor
of something else saner and easier to work with.
Notes on the above:
1. This is probably best rolled into 2.
2. Manuel has convinced me that quotaon should remain specific to the
old-style quota system (quota1), where like quotacheck it's part of
the fsck and mount process. The proposed API should be adjusted to
match. There should also be a function in the API to check if
quotacheck/quotaon is required for a given volume, and also, functions
to check if there are external quota files (which might be a separable
property, though it isn't right now) and if so retrieve their names.
3. There's already been some discussion of the compat issues in this
thread. Basically it boils down to: if you send a program material
that it's not expecting to receive, it won't be able to cope with it
and will fail/die/crash. This is true whether the material is binary
or a proplib bundle or text or whatever else.
*If*, and this is a very large if, you can know/plan in advance what
changes are likely to happen, you can define the format of the
material you send back accordingly and write the programs receiving it
to anticipate the possible changes and behave in some predetermined
suitable fashion, usually by ignoring material it doesn't
recognize. However, except for a very small class of changes, suitable
behavior can't be implemented in advance; furthermore, given that
proplib has no schema support and no way to document the format of a
proplib bundle except arbitrary natural-language text, it is unlikely
that a set of planned/expected format changes can be specified clearly
enough for this compat method to be workable in the long term.
Beyond that, quotas are a pretty static concept. The quota2 code
brought the first change to the (abstract) quota formats in many
years, by moving to 64-bit values; it is unlikely that there will be
another change until it's time to move to 128-bit block counters... if
that ever happens. The only *likely* change is to have more things to
apply quotas to besides blocks and inodes, and the binary format I
proposed covers that. Everything else that's been suggested is wild
speculation. (I particularly I don't believe in Manuel's suggestion
that we might want to apply quotas to things whose ID is a string;
even if we were to start assigning on-disk objects to belong to things
identified by strings, because that belonging has to be stored in the
inode and in other places it'll end up being an ID number with a
translation table somewhere... just like usernames and group names.)
Between all these things I see no real compatibility advantage to
using proplib for the user<->kernel transfer encoding, and there are a
lot of disadvantages.
4. If using split on the output of quota/repquota/whatnot isn't good
enough (in some specific places we may want a machine-readable-output
option) then the best way to access the quota system from Perl or
Python (or Ruby or Lua or ...) is with a set of bindings for the new
proposed libquota. This should be straightforward to set up once the
new libquota is in place. I think the current quotactl(8) should just
be dropped. Among other things, I've been told that XML-based user
interfaces are specifically prohibited by act of Core.
Some other notes:
- As far as I can tell there is not and never has been support for
manipulating quotas on unmounted filesystems. I don't see that there
should be either. I don't know what Manuel is talking about in this
regard.
- Since quot(8) isn't a quota tool, it's not involved in this.
However, it's not particularly clear from its documentation that it's
not a quota tool, so I'm going to fix that at some point. I'm also
going to go clean it up so it can support multiple filesystem types.
- We still need suggstions for better terminology than "quota classes"
and "quota types".
--
David A. Holland
dholl...@netbsd.org
