[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