Hello, > On Wed, Jan 16, 2002 at 04:53:44PM -0800, Andrew Morton wrote: > > "Branko F. Gracner" wrote: > > > > > > /dev/hda8 on /export/home type ext3 > > > (rw,nosuid,usrquota=/var/quotas/export.home.usrquota, > > > grpquota=/var/quotas/export.home.grpquota) > > > > woah. What are you trying to do here? > > Looks like we've got a problem here. :) Sorry, Branko, but I had no > idea it was remotely possible to do this with quotautils, and if you I must admit that before I've almost rewritten all quota utilities I didn't know this either :). I personaly don't like it too much (I think of quotas more like fs metadata) but I keep it for compatibility... > try it, it *will* fail with ext3 in exactly this manner. We just need > to find a way for the kernel to prevent it in a clean manner, so that > it rejects the quotaon request but tells the user why. EXDEV (someone will have to return this but see below) and reasonable handling in utils? > > The grpquota and usrquota mount options are now ignored, > > Not by quotautils. quotaon will supply the quota file location from > fstab to the kernel. Exactly. > Jan, there's something else that ext3 has to hack around in the kernel > dquot.c: we don't have any callback from dquot into the filesystem > when a quotaon occurs, so we have to play tricks either to set > data-journaling on the quota file, or to set up the superblock dq_ops > if we want to wrap quota calls for the sake of journaling. > > A quota-enabled ext3 filesystem *must* have the quota files residing > on the same disk as the rest of the data. There is simply no way to > guarantee transactions across multiple different disks. Jan, have you > any thoughts about how best to enforce this? Ideally, if ext3 could > trap the quotaon then it could check the quota file locations at that > point, but we can't since sys_quotactl doesn't interact with the > filesystem at all during quotaon except to open the files. I think there's no problem with creating callback on quotaon which would check whether quota on is possible for filesystem and do other things... Regarding the dq_ops - they interact nontrivially with functions in quotaops.h - e.g. they do lock_kernel(), dquot_alloc_block() is never called when quotas are turned off, update of i_blocks is done inside of those functions etc. This was done due to efficiency but we'll probably have to change it when filesystem can specify it's own callbacks. > Even a kernel-internal O_QUOTA flag used by sys_quotactl would be > enough of a hint, I think. Honza PS: I'm not going to be on mail for a week so I won't be responding... -- Jan Kara <jack@suse.cz> SuSE CR Labs
