[Lustre-devel] Moving forward on Quotas

Nikita Danilov Nikita.Danilov at Sun.COM
Sat May 31 12:11:34 PDT 2008


Ricardo M. Correia writes:

 > I am assuming snapshots should not have any effect on quotas, right?

That's the problem: on the one hand, users want to use quota to control
actual disk usage, e.g., to not run out of disk space. For this, one
wants to include snapshots into quota. On the other hand, space in
snapshots is not easily reclaimable, which is not very convenient,
because user might be without a way to clean up space. Note that this
situation is possible without snapshots: other user can hard-link your
file from a directory to which you have no access.

 > 
 > Hmm.. I think so, but I think we should not rely on this always being 2,
 > I think we should allow the list to have an unbounded size, and let the
 > commit callbacks notify when an entry can be pruned from the list.

Right.

 > > But we don't have to, if we make ->space_usage() idempotent, i.e.,
 > > taking an absolute space usage as a last argument, rather than delta. In
 > > that case, DMU is free to call it multiple times, and client has to cope
 > > with this. (Hmm... I am pretty sure this is what I was thinking about
 > > when composing previous message, but confusing signed __s64 delta
 > > somehow got in, sorry.)
 > 
 > 
 > Ok, that clears my previous concern.
 > But in this case, how do you know how much you need to add or subtract
 > to a quota when an object changes size?
 > I am guessing that you'd need to at least write the previous object size
 > as part of the pending list, so that when you're recovering you'd know
 > the delta..

Yes, something similar to what data-bases do for redo logging, where the
same log entry can be replayed multiple times.

 > 
 > Cheers,
 > Ricardo
 > --

Nikita.



More information about the lustre-devel mailing list