guru input needed! (re-inventing disk quotas)

[Kurt Wall]

Scribbling feverishly on April 08, Douglas J Hunley managed to emit:
> Morning all:
> 	I have a client that wants to migrate to Linux from Solaris, but one of their 
> main "gotchas" is the quota support in Linux. They believe (as do I) that 
> quotas seem to be the first thing broken (and the last thing fixed) whever a 
> change is introduced into the fs or block layers of the kernel. They 
> currently have a *very* detailed accounting system in place that charges 
> their internal customers (departments) based on disk usage, CPU usage, 
> network utilization, etc. They don't want to lose any of this when they go to 
> Linux. I believe I have solutions for everything but the disk quotas. 
> However, I have what I think is a neat idea for solving the disk issue. I 
> would like opinions.

Last I checked, the quota support worked just fine. I wrote about
using it in my last book, which used kernel 2.4.7.

> 	What I propose is this:
> 1. create /loops on the main disk server
> 2. for each user on the system, use 'dd' to preallocate a file in /loops:
> 	dd if=/dev/zero of=/loops/joe bs=1k count=10240
>    which would create a 10M (if my math is right) file called /loops/joe
> 3. chown joe:users /loops/joe
> 4. configure the automounter to mount the newly allocated file as joe's $HOME
> 	mount -o loop /loops/joe /home/joe

This sounds like an administrative nightmare. Maybe not now, but it
isn't hard to imagine it quickly becoming one.

> Obviously, I would have to create a local 'create user' script to allocate the 
> file, and add the entry into the automounter config.
> 
> The biggest caveat I can see is that "joe" would be charged for 10M even if he 
> only used 2M. I already ran this concerns by them, and they seemed OK with 
> it. They said they would be happy selling disk in chunks like this. And we 
> could always "extend" the allocation be creating a joe2 of the new size, and 
> then copying the contents over and moving joe2 over top of joe.
> 
> This will free them from worrying about whether or not the current quota code 
> is working properly, and would easily enforce the hard limit. (there's no way 
> that joe could write 11M of stuff. he'd get ENOSPACE).
> 
> Thoughts?

My main thought is that it seems complicated and I don't hear that
you've actually investigated whether or not the quota code is still
working. And, as I said, the quota stuff worked just fine in 2.4.7
and I haven't seen anything to the effect that it wasn't or isn't.

The principle is KISS.

Kurt
-- 
Excellent time to become a missing person.