Re: crashing with ext3

[Jan Kara <jack suse cz>]

  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