[ On Thursday, December 18, 2003 at 23:34:13 (+0700), Robert Elz wrote: ]
> Subject: Re: bin/23725: possible quotacheck enhancement 
>
> It looks like it may still have the infinite loop on id==LONG_MAX bug
> in there (assuming that id actually gets into the quota file), but
> aside from that, there isn't much that can be done to speed up repquota
> really - you don't want it to skip reporting users just because they're
> not in the passwd file (or groups & group file) - and that's just about
> the only real optimisation that can be done.

For my purposes it would be nice to have an option to only report quotas
for users that do exist in the passwd db -- that would make a script
that only reports over-quota users a bit more efficient (and thus more
likely to be run) on any system with a "-2" user.  (I clean out files
that no longer have valid owners by other means and I don't normally
care about the per-user quotas of non-existant users, though a
quicker-to-calculate total for all un-owned files would be nice.)

Repquota itself could probably use an option to only print over-quota
(hard or soft or over a certain percentage) users (or groups).  I
suspect that's a question often asked by those who do use FS quotas, and
I suspect there are quite a variety of similar but all slightly
different scripts floating around for generating such a report from the
full repquota output.

> repquota really has to read the whole quota file (a "read skipping holes"
> syscall would help it...) to report what is there, reading that giant
> file is simply going to take time, even if the giant is mostly just
> a shell around a lot of empty space.

Agreed, and on my test system they sure giant balls of near-vacuum:

	# ls -ls /*/quota.user 
	40 -rw-r-----  1 root  operator  4294967264 Dec 17 17:36 /build/quota.user
	80 -rw-r-----  1 root  operator  4294967264 Dec 17 17:36 /mfbd/quota.user

:-)

> That, or perhaps better, quotacheck and fsck could just agree to go
> their separate ways, and end that wacky file sharing/stealing stuff.

It appears that's what the FreeBSD folks have done -- i.e. they have
given quotacheck its own private, and now very different, copy of the
preen.c source.

I think a better solution would be to factor out the functionality so
that there's a more generic "run at most N concurrent processes using
this 'function' passing each instance an anonymous pointer from this
'list', starting a new process as each existing one completes until the
pointers in the list are exhausted" utility function (i.e. for libutil).
In fact I've probably already written this function, if only I can
remember where I used it.

Then along with perhaps a more specific fstab-related function for
creating that list of pointers out of copies of the struct fstab results
selected based on specified options (e.g. like the code already in
sbin/dump/optr.c:getfstab()) and sorting the list based on passno
values, each of quotacheck and fsck could do their thing without having
to contain separately maintained but very similar functionality.

>   | Turning off quotas, removing the quota.user files, and
>   | re-running quotacheck, "fixed" it (even with '-q'), provided I do one
>   | filesystem at a time by hand.
> 
> The -q there is irrelevant - if the quota file is removed, -q does
> nothing - its sole purpose is to avoid reading lots of (your) huge quota
> files when almost everything out there is going to be hole.

Ah, of course!


-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>