[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: crashing with ext3


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]