Thread: [Jfs-discussion] default quota limits in linux (via quotactl())
Brought to you by:
blaschke-oss,
shaggyk
From: Stefan (m. M. <me...@me...> - 2003-01-27 17:41:13
Attachments:
2.5.59-defquota.diff
|
Hi Alexander and *, I would like linux to handle default quota limits like NTFS 5 do it. So if a new user is added to the system and start to own disk space on a filesystem he should get the default quotas for the specified FS as his own quotas. Now a new user has unlimited disk space until root explicit sets quota limits for this user. I have searched in google to find another unix witch allready implements this feature, but I didn't find any. So I decided to add two (four) new cmd's to quotactl(), Q_SETDEFQUOTA Q_GETDEFQUOTA and for the XFS Quotas Q_XSETDEFQLIM Q_XGETDEFQUOTA this call should take the same paramter's as the Q_GETQUOTA /Q_XGETQUOTA .. cmd's but the uid/gid should be ignored here and the filesystem defaults should be get or set. I think this should be an easy task to be implemented in the filesystems witch allready support quotas. I attach a patch witch modify the quotactl system call for this. the implemetation inside the filesystems, should be done by the maintainers:-) PS: I'm currently using XFS and it would be very cool if the default quota limits could implemented very fast...:-) I hope I will get feedback :) thanks anyway... please cc me: in all replies:-) metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher <me...@me...> |
From: Stephen C. T. <sc...@re...> - 2003-01-27 19:23:52
|
Hi, On Mon, 2003-01-27 at 14:41, Stefan (metze) Metzmacher wrote: > I would like linux to handle default quota limits like NTFS 5 do it. > > So if a new user is added to the system and start to own disk space on a > filesystem he > should get the default quotas for the specified FS as his own quotas. That's a user-space problem. A new user typically won't have a writable area within /home until the sysadmin has created the new home directory, so it's really up to the sysadmin to make sure that the quota for the home filesystem has been set at the same time. > I have searched in google to find another unix witch allready implements > this feature, > but I didn't find any. The kernel doesn't need it --- just do it in the user-space user config tool. Cheers, Stephen |
From: Stefan (m. M. <me...@me...> - 2003-01-28 09:43:46
|
At 16:22 27.01.2003 +0000, Stephen C. Tweedie wrote: >Hi, > >On Mon, 2003-01-27 at 14:41, Stefan (metze) Metzmacher wrote: > > > I would like linux to handle default quota limits like NTFS 5 do it. > > > > So if a new user is added to the system and start to own disk space on a > > filesystem he > > should get the default quotas for the specified FS as his own quotas. > >That's a user-space problem. A new user typically won't have a writable >area within /home until the sysadmin has created the new home directory, >so it's really up to the sysadmin to make sure that the quota for the >home filesystem has been set at the same time. what is with a filesystem in witch the user has write access because of group memberships. or/and the user's/group's are stored in LDAP: then user are added directly to the LDAP diretory and they maybe available on a large amount of servers and it's a pain to manage the quotas for each filesystem on each server. also it's hard to handle changed group memberships... I think there's a good reason that NTFS 5 support default quota limits. And it would be cool if linux would support them too. it's not hard to implement and it would make thinks much easier to handle in large environments! > > I have searched in google to find another unix witch allready implements > > this feature, > > but I didn't find any. > >The kernel doesn't need it --- just do it in the user-space user config >tool There're many things, witch are not inevitable needed in the kernel, but they all make the life easier. Would it really hurt that much if the kernel would support it? metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher <me...@me...> |
From: Stefan (m. M. <me...@me...> - 2003-01-28 09:54:15
|
At 16:22 27.01.2003 +0000, Stephen C. Tweedie wrote: >That's a user-space problem. A new user typically won't have a writable >area within /home until the sysadmin has created the new home directory, >so it's really up to the sysadmin to make sure that the quota for the >home filesystem has been set at the same time. What is if we have 500.000 users and 300.000 group in LDAP and set up a new server, witch is intended to store data from ~1000 users 500 group should the admin really run setquota ... for each of the 500.000 users and 300.000 group that's are 800.000 quota entries in the filesystem and only 1500 are really used ans this entries cost disk space too, so if we have two default entries (one for users and one for groups) then only every user witch really uses this filesystem would get a quota entry when he starts to own diskspace on this filesystem and we would have only 1502 quota entries stored on disk! metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher <me...@me...> |
From: Jan H. <bu...@uc...> - 2003-01-28 12:33:44
|
On Tue, Jan 28, 2003 at 07:54:08AM +0100, Stefan (metze) Metzmacher wrote: > At 16:22 27.01.2003 +0000, Stephen C. Tweedie wrote: > >That's a user-space problem. A new user typically won't have a writable > >area within /home until the sysadmin has created the new home directory, > >so it's really up to the sysadmin to make sure that the quota for the > >home filesystem has been set at the same time. > > What is if we have 500.000 users and 300.000 group in LDAP > > and set up a new server, witch is intended to store data from ~1000 users > 500 group > > should the admin really run setquota ... for each of the 500.000 users and > 300.000 group > > that's are 800.000 quota entries in the filesystem and only 1500 are really > used > > ans this entries cost disk space too, so if we have two default entries > (one for users and one for groups) then only every user witch really uses > this filesystem would get a quota entry when he starts to own diskspace on > this filesystem and we would have only 1502 quota entries stored on disk! It still isn't a kernel problem, but a user-space one. You need to get or write a PAM module, that will check wether quotas are set for user being authenticated and if not, set them. You could even store the qutoas in the LDAP (or some other) database and check them when a user logs in... ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Jan H. <bu...@uc...> - 2003-01-28 12:46:50
|
On Tue, Jan 28, 2003 at 01:40:14AM -0800, Chris Wedgwood wrote: > On Tue, Jan 28, 2003 at 10:32:50AM +0100, Jan Hudec wrote: > > > It still isn't a kernel problem, but a user-space one. You need to > > get or write a PAM module, that will check wether quotas are set for > > user being authenticated and if not, set them. You could even store > > the qutoas in the LDAP (or some other) database and check them when > > a user logs in... > > consider 1 million users where only a small percentage of them will > ever write to the fs ... why even store 1 million quota values > needlessly at all? While all the 1 milion users actualy ever LOG IN that site? And... do they ever log into that site AT THE SAME MOMENT? > surely the argument for a default here isn't a terrible one? ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Jan H. <bu...@uc...> - 2003-01-28 13:58:13
|
On Tue, Jan 28, 2003 at 02:13:10AM -0800, Chris Wedgwood wrote: > On Tue, Jan 28, 2003 at 10:46:19AM +0100, Jan Hudec wrote: > > > While all the 1 milion users actualy ever LOG IN that site? > > what? So you can only setquota for the users that actualy log in. > consider a mail server (or series thereof) and quota for mail... Well, it get's complicated, but you still can setquota in the local delivery process... I know it get's a bit complicated... > > And... do they ever log into that site AT THE SAME MOMENT? > > presumably not ... most machines only allow 995,000 simultaneous > logins unless you have an extra 2M in your 386 Because you could remove the quotas again for users, that logged in, but their quota is still the default... ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Jan H. <bu...@uc...> - 2003-01-28 15:37:40
|
On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: > > > So you can only setquota for the users that actualy log in > > the API allows you to set quota for any valid uid/gid Yes, it does. But since there is many more valid users than those actualy using the system, you don't want to... And a logged in user is sure valid, so no problem there, right? > > Well, it get's complicated, but you still can setquota in the local > > delivery process... I know it get's a bit complicated... > > sure, this is a perfectly legitimate argument and a fairly reasonable > solution to this case If it finaly got too complicated, you could add a simple code to kernel, that would run_usermodehelper and provide a user mode program to fix things up. That might even get a chance of being accepted. (And it would be more flexible since it can get the default quota from LDAP etc...) However as long as it's manageable in userspace, do it in userspace... All services that log in users can use PAM nowadays, so there it is quite easy and all services that can run on behalf of users have some hooks where the fixup command can be run too. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Stefan (m. M. <me...@me...> - 2003-01-28 16:35:38
|
At 13:37 28.01.2003 +0100, Jan Hudec wrote: >On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: > > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: > > > > > So you can only setquota for the users that actualy log in > > > > the API allows you to set quota for any valid uid/gid > >Yes, it does. But since there is many more valid users than those >actualy using the system, you don't want to... And a logged in user is >sure valid, so no problem there, right? > > > > Well, it get's complicated, but you still can setquota in the local > > > delivery process... I know it get's a bit complicated... > > > > sure, this is a perfectly legitimate argument and a fairly reasonable > > solution to this case > >If it finaly got too complicated, you could add a simple code to kernel, >that would run_usermodehelper and provide a user mode program to fix >things up. That might even get a chance of being accepted. (And it would >be more flexible since it can get the default quota from LDAP etc...) is there an example( another place in the kernel where the kernel callback a userspace tool) can you point me to the place (the function) where the quota entry/object will be created for new users, so this should be the location where the userspace tool should be callback... that would be a cool solution, witch I could accept too:-) metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher <me...@me...> |
From: Walt H <wal...@co...> - 2003-01-28 18:18:53
|
I believe that the hotplug stuff does this. When a new hotpluggable pci, usb etc... device is plugged into the system, it triggers /sbin/hotplug to run to look for the appropriate kernel module to provide a driver. -Walt Stefan (metze) Metzmacher wrote: > At 13:37 28.01.2003 +0100, Jan Hudec wrote: > >> On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: >> > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: >> > >> > > So you can only setquota for the users that actualy log in >> > >> > the API allows you to set quota for any valid uid/gid >> >> Yes, it does. But since there is many more valid users than those >> actualy using the system, you don't want to... And a logged in user is >> sure valid, so no problem there, right? >> >> > > Well, it get's complicated, but you still can setquota in the local >> > > delivery process... I know it get's a bit complicated... >> > >> > sure, this is a perfectly legitimate argument and a fairly reasonable >> > solution to this case >> >> If it finaly got too complicated, you could add a simple code to kernel, >> that would run_usermodehelper and provide a user mode program to fix >> things up. That might even get a chance of being accepted. (And it would >> be more flexible since it can get the default quota from LDAP etc...) > > > is there an example( another place in the kernel where the kernel > callback a userspace tool) > > can you point me to the place (the function) where the quota > entry/object will be created for new users, > so this should be the location where the userspace tool should be > callback... > > that would be a cool solution, witch I could accept too:-) > > > > > metze > ----------------------------------------------------------------------------- > > Stefan "metze" Metzmacher <me...@me...> > |
From: Stefan M. <ste...@me...> - 2003-01-28 18:28:06
|
At 07:18 28.01.2003 -0800, Walt H wrote: >I believe that the hotplug stuff does this. When a new hotpluggable pci, >usb etc... device is plugged into the system, it triggers /sbin/hotplug to >run to look for the appropriate kernel module to provide a driver. I'll look at this... is get_empty_dquot() or dqget() the right place to callback the user space tool? >>>If it finaly got too complicated, you could add a simple code to kernel, >>>that would run_usermodehelper and provide a user mode program to fix >>>things up. That might even get a chance of being accepted. (And it would >>>be more flexible since it can get the default quota from LDAP etc...) >> >>is there an example( another place in the kernel where the kernel >>callback a userspace tool) >>can you point me to the place (the function) where the quota entry/object >>will be created for new users, >>so this should be the location where the userspace tool should be callback... >>that would be a cool solution, witch I could accept too:-) >> >> >>metze >>----------------------------------------------------------------------------- >> >>Stefan "metze" Metzmacher <me...@me...> ----------------------------------------------- Stefan Metzmacher ste...@me... |
From: Juan Q. <qui...@ma...> - 2003-01-29 19:34:29
|
>>>>> "stefan" == Stefan (metze) Metzmacher <me...@me...> writes: stefan> At 13:37 28.01.2003 +0100, Jan Hudec wrote: >> On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: >> > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: >> > >> > > So you can only setquota for the users that actualy log in >> > >> > the API allows you to set quota for any valid uid/gid >> >> Yes, it does. But since there is many more valid users than those >> actualy using the system, you don't want to... And a logged in user is >> sure valid, so no problem there, right? >> >> > > Well, it get's complicated, but you still can setquota in the local >> > > delivery process... I know it get's a bit complicated... >> > >> > sure, this is a perfectly legitimate argument and a fairly reasonable >> > solution to this case >> >> If it finaly got too complicated, you could add a simple code to kernel, >> that would run_usermodehelper and provide a user mode program to fix >> things up. That might even get a chance of being accepted. (And it would >> be more flexible since it can get the default quota from LDAP etc...) stefan> is there an example( another place in the kernel where the kernel stefan> callback a userspace tool) devfsd <-> devfs /me runs Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy |