Hi, 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 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. > The grpquota and usrquota mount options are now ignored, Not by quotautils. quotaon will supply the quota file location from fstab to the kernel. 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. Even a kernel-internal O_QUOTA flag used by sys_quotactl would be enough of a hint, I think. Cheers, Stephen
