Very Computer

A _LOT_ of people need quotas on their multiuser systems, and surely inclusion
of the patch into 1.3.x is the ideal place for its refinement before a stable
1.4.x comes out.

To those people not requiring quotas, please don't post saying not to include
this feature, as quotas always have been and likely always will be, a config
time option, even with the patch applied.

Inclusion of quotas into the kernel will prevent the need for some poor person
to maintain the patch for the latest 1.3.x kernel (look at ftp://ftp.cistron.nl
/pub/linux), as was the case with the kswap patches until pressure from fans
of the patch got it included into 1.3.34 or thereabouts.

-- Chris

                   >> PGP key available on request <<
                >>Presence in pub available on request<<

  I am posting, wondering why the quotas patch has not found its way into the
  1.3.x development series of kernels. I have seen this query asked by a lot of
  different people, but not on this newsgroup (apologies if this HAS been
  discussed recently).

  A _LOT_ of people need quotas on their multiuser systems, and surely inclusion
  of the patch into 1.3.x is the ideal place for its refinement before a stable
  1.4.x comes out.

  To those people not requiring quotas, please don't post saying not to include
  this feature, as quotas always have been and likely always will be, a config
  time option, even with the patch applied.

  Inclusion of quotas into the kernel will prevent the need for some poor
  person to maintain the patch for the latest 1.3.x kernel (look at
  ftp://ftp.cistron.nl /pub/linux), as was the case with the kswap patches
  until pressure from fans of the patch got it included into 1.3.34 or
  thereabouts.

Unless something has changed, it was my understanding that the reason the
quota patches were not being included in the standard kernel is that they
don't really work correctly.  I recall someone made a long post detailing
the problems with the quota patches as presently implemented, but I don't
believe I saved it.  In any event, pressure is not the way to get something
included in the kernel -- a good implementation is.

                Leonard

Please, this has been beaten to death in a recent thread over the
last few days. Go back and reread it.

: Unless something has changed, it was my understanding that the reason the
: quota patches were not being included in the standard kernel is that they
: don't really work correctly.  I recall someone made a long post detailing
: the problems with the quota patches as presently implemented, but I don't
: believe I saved it.  In any event, pressure is not the way to get something
: included in the kernel -- a good implementation is.

:               Leonard

Sorry I missed the earlier thread on quotas, I would be grateful if someone
would fill me in on how the debate closed. Maybe something _HAS_ changed,
however, as I was just browsing the two different quota patches, one for
1.2.13 and the other for 1.3.<something recent>. It seems the 1.3.x patches
no longer kludge quotas onto the VFS, they now only work on ext2 filesystems,
on an ext2 inode basis. Anyone else interested can find the latest quota
patches on ftp://ftp.cistron.nl/pub/os/linux/kernel/v1.3 or something very
similar.

My point really was, even if the patches are buggy, surely the 1.3.x series
of development kernels is the place to refine them. But, if the way they
are actually implemented is kludgy, then well... fair enough. Two questions
to end on: Is anyone else working on a better implementation of quotas, if
the latest implementation is poor?
And are they scheduled for inclusion into 1.4.x?

Cheers,

-- Chris
                   >> PGP key available on request <<
                >>Presence in pub available on request<<

| Sorry I missed the earlier thread on quotas, I would be grateful if someone
| would fill me in on how the debate closed. Maybe something _HAS_ changed,
| however, as I was just browsing the two different quota patches, one for
| 1.2.13 and the other for 1.3.<something recent>. It seems the 1.3.x patches
| no longer kludge quotas onto the VFS, they now only work on ext2 filesystems,
| on an ext2 inode basis. Anyone else interested can find the latest quota
| patches on ftp://ftp.cistron.nl/pub/os/linux/kernel/v1.3 or something very
| similar.

It's not clear that VFS is the wrong place to put quotas, since it
would avoid having them in one place and not the other. Don't read
this as a statement of support for any implementation, just a
general comment on the pros and cons.

A general quota would be nice because there are bound to be
journaling, compressing, whatever filesystems. *If* it were possible
to put quotas at a lower level it could make the kernel smaller and
faster when using several types.

Technical musing in hope of clarification here...

: It's not clear that VFS is the wrong place to put quotas, since it
: would avoid having them in one place and not the other. Don't read
: this as a statement of support for any implementation, just a
: general comment on the pros and cons.

: A general quota would be nice because there are bound to be
: journaling, compressing, whatever filesystems. *If* it were possible
: to put quotas at a lower level it could make the kernel smaller and
: faster when using several types.

  I concur.  I'm thinking of doing something very similar to
Supermount (automagic floppy mount/umount) so that you:

 *) Start your 'Quota Server'
 *) Mount your filesystems as a subsystem under quotafs

   User writes/reads to any quotafs would be verfiried
by the Quota Server (which, in turn could check over
the network with other Quota Servers), and if the user was
denied, would prevent the read/write/create/whatever.

So, to summarize:
   User Space:  Quota Server
                  *) Would use SUN RPC/named pipe to communicate (???)
                  *) Persistent quota database
                  *) Could be extended to handle ACLs (???)
   Kernel:      Anything mounted under quotafs would
                  *) Have all accesses checked with the quotaserver
                  *) If the quotaserver is dead, only root
                     can access quotafs systems.

 This way, the kernel stays relatively clean, quotafs could
be a loadable module (like I've done to supermount), and
all the hairiness would be done in user-space.

--
Copyright 1995 Jason McMullan; all rights reserved; license for the Microsoft
Network to distribute this text for US $100,000 per copy is hereby granted; all
other use of this text by the Microsoft Network, including storing, relaying,
or reuse is expressly prohibited; distribution by the Microsoft Network
indicates full acceptance of the licensing terms.

|   I concur.  I'm thinking of doing something very similar to
| Supermount (automagic floppy mount/umount) so that you:
|
|  *) Start your 'Quota Server'
|  *) Mount your filesystems as a subsystem under quotafs
||
|    User writes/reads to any quotafs would be verfiried
| by the Quota Server (which, in turn could check over
| the network with other Quota Servers), and if the user was
| denied, would prevent the read/write/create/whatever.

So you would quotas which work over the net via NFS as well? That
would certainly be a great feature.

| So, to summarize:
|    User Space:  Quota Server
|                   *) Would use SUN RPC/named pipe to communicate (???)
|                   *) Persistent quota database
|                   *) Could be extended to handle ACLs (???)
|    Kernel:      Anything mounted under quotafs would
|                   *) Have all accesses checked with the quotaserver
|                   *) If the quotaserver is dead, only root
|                      can access quotafs systems.
|
|  This way, the kernel stays relatively clean, quotafs could
| be a loadable module (like I've done to supermount), and
| all the hairiness would be done in user-space.

I wouldn't bet the price of a case of good beer that there will ever
be any support in the kernel, but at least the patches will be
smaller ;-)

This sounds like a great implementation!

--
Copyright 1995 Jason McMullan; all rights reserved; license for the Microsoft
Network to distribute this text for US $100,000 per copy is hereby granted; all
other use of this text by the Microsoft Network, including storing, relaying,
or reuse is expressly prohibited; distribution by the Microsoft Network
indicates full acceptance of the licensing terms.