<HTML>
<HEAD>
<TITLE>Re: [Lustre-devel] Moving forward on Quotas</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>For CIFS quota and user ids get in touch with Matt Wu and Mike Shapiro. There are special interfaces in ZFS/DMU for better windows support that we probably need to leverage.<BR>
<BR>
Peter<BR>
<BR>
<BR>
On 5/29/08 5:07 AM, "Ricardo M. Correia" <<a href="Ricardo.M.Correia@Sun.COM">Ricardo.M.Correia@Sun.COM</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On Qui, 2008-05-29 at 00:06 +0400, Nikita Danilov wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Well... that's just renaming uid and gid into opaqueid0 and<BR>
opaqueid1. :-)<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
It may be simple for POSIX uids/gids, but maybe not for CIFS user ids (but since there is a mapping table it may be also be simple, I'm not sure).<BR>
I think it would make sense to give it a list of opaque ids, instead of just opaqueid0 and opaqueid1 (maybe a file could belong to multiple groups or maybe we can think of other creative ideas in the future..).<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> So on one hand we have to add a couple of parameters to all dmu entry<BR>
points that can allocate disk space. On the other hand we have something<BR>
like<BR>
<BR>
typedef void (*dmu_alloc_callback_t)(objset_t *os, uint64_t objid, long bytes);<BR>
<BR>
void dmu_alloc_callback_register(objset_t *os, dmu_alloc_callback_t cb);<BR>
<BR>
with dmu calling registered call-back when blocks are actually allocated<BR>
to the object. Advantage of the later interface is that dmu implements<BR>
only mechanism, and policy ("user quotas" and "group quotas") is left to<BR>
the upper layers to implement.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
I don't see why that would be an advantage over what we had planned to do.<BR>
The plan we discussed with the ZFS team was to make the DMU do space accounting internally by opaque ids, so the quota policy/enforcement would still be left to the upper layers to implement.<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
If quota management and storage are<BR>
completely encapsulated within dmu, then dmu has to provide full quota<BR>
control interface too, and that interface has to be exported from osd<BR>
upward. For one thing, implementation of this interface is going to take<BR>
a lot of time.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Again, the plan was for the DMU to do only space accounting, the actual quota management and enforcement would be implemented in Lustre.<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
> For things that requires knowledge of DMU internals (like space<BR>
> accounting, spacemaps, ...) it shouldn't be the DMU consumer that has to<BR>
> write during the txg sync phase, it should be the DMU because only the<BR>
> DMU should know about its internals.<BR>
<BR>
I don't quite understand this argument. DMU already has an interface to<BR>
capture a buffer into a transaction and to modify it within this<BR>
transaction. An interface to modify a buffer after transaction was<BR>
closed, but before it is committed is no more "internal" than the first<BR>
one. It is just places more restrictions on what consumer is allowed to<BR>
do with the buffer.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
What I mean is that IMO a consumer of a filesystem shouldn't have to know intimate details of how the filesystem (in this case, the DMU) works.<BR>
For instance, so far Lustre had no idea that transactions are actually grouped into transaction groups and it had no idea about transaction group states.<BR>
<BR>
Allowing modification of buffers by an upper layer when a transaction group is already syncing is not a very elegant way to solve this IMHO (compared with our previous plan).. :-)<BR>
<BR>
Cheers,<BR>
Ricardo<BR>
<BR>
--<BR>
<IMG src="cid:3295161393_7114933" ></SPAN><FONT SIZE="2"><SPAN STYLE='font-size:10pt'><B>Ricardo Manuel Correia<BR>
</B>Lustre Engineering<BR>
</SPAN></FONT><SPAN STYLE='font-size:11pt'><BR>
</SPAN><FONT SIZE="2"><SPAN STYLE='font-size:10pt'><B>Sun Microsystems, Inc.<BR>
</B>Portugal<BR>
Phone +351.214134023 / x58723<BR>
Mobile +351.912590825<BR>
Email <a href="Ricardo.M.Correia@Sun.COM">Ricardo.M.Correia@Sun.COM</a><BR>
</SPAN></FONT><SPAN STYLE='font-size:11pt'><HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>_______________________________________________<BR>
Lustre-devel mailing list<BR>
<a href="Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a><BR>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-devel">http://lists.lustre.org/mailman/listinfo/lustre-devel</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>