> > So the only possibility that I see is that each time you read the inode
> > you check whether its TID is OK. But that means going through dirs everytime
> > you read some inode which doesn't look nice to me...
> >
>
> Have a look at the code and see where treequota_check is called.
>
> It is called every time a "lookup" is done, whether the result is in
> the cache or not. If the lookup found something, then you have a
> inode and it's parent right there in the cache. treequota_check
> checks that the tid of the child matches that of the parent, and
> changes it if not. So the overhead is very small for the common case
> where the tid is correct.
>
> It just tests:
> is inode NULL
> are treequotas enabled for this inode
> does the tid of the child match that of the parent (or the uid of
> the child if parent.tid==0
OK. I've seen the code and I agree it's not real problem.
> > >
> > > It is, I think, the 'best' solution that is possible.
> > I also don't see a better solution but I'm not sure this solution is good
> > enough to be implemented (to me it looks more like a hack than a regular
> > part of system...).
>
> I accept that it does look like a bit of a hack.
> But I think it is simple, understandable, and predictable.
> And I think that (for me) the value of tree quotas is more than enough
> to offset that cost.
I just don't like the idea that when you do lookup you can suddenly get
Disk quota exceeded... I'd concern this behaviour a bit nonintuitive. I agree
that if root makes lookup of every file after moving directories then this
doesn't happen but still I don't like the design :).
Honza
-- Jan Kara <jack@suse.cz> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 21:00:36 EST