On Thursday October 25, jack@suse.cz wrote:
> > So if you move a directory between quota trees, then the usages will
> > be wrong in the first instance. But only root can make this happen.
> > However, there is an easy way to fix it: just run a find or a du in
> > the new tree.
> Umm.. I'm not sure about one thing: When you move the dir between the
> trees when you update TID's? I understood that not during the move...
That is right. Not during the move.
Well... the tid of the directory itself changes during the move. The
tid's of descendants change later.
> 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
> >
> > 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.
NeilBrown
-
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:30 EST