[Lustre-devel] Moving forward on Quotas
Nikita Danilov
Nikita.Danilov at Sun.COM
Thu May 29 01:39:53 PDT 2008
Ricardo M. Correia writes:
> On Qui, 2008-05-29 at 01:11 +0400, Nikita Danilov wrote:
>
> > Hm.. seems I am confused. If ZFS stores quota table internally, how this
> > table is available to the upper layers, to implement policy?
>
>
> uint64_t dmu_get_space_usage(objset, opaque_id)?
It is not immediately clear how chown and chgrp can be implemented on
top of this. Plus an interface to iterate over this table is most likely
required for quota tools.
To return to the question why using call-backs notifying about object
space allocation changes is preferable to maintaining space allocation
per-id in file system: opaqueid's have to be visible not only in the dmu
interface, but also in osd interface, because quota policy is
implemented above osd. But
- osd knows nothing about users and groups (it uses capability-based
access control), and its interface has to be expanded to pass
through identifiers that it doesn't understand and doesn't
use. This looks wrong. osd operates on objects, identified by
fids, and it would be much more natural to do space accounting on
the object granularity.
- osd interface is identical on all platforms, so, in effect, zfs
space accounting interface is enforced on ldiskfs (and on all
possible future back-ends).
> Ricardo Manuel Correia
> Lustre Engineering
Nikita.
More information about the lustre-devel
mailing list