<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.1">
</HEAD>
<BODY>
On Qui, 2008-05-29 at 00:06 +0400, Nikita Danilov wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Well... that's just renaming uid and gid into opaqueid0 and
opaqueid1. :-)
</PRE>
</BLOCKQUOTE>
<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>
<BLOCKQUOTE TYPE=CITE>
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>
</BLOCKQUOTE>
<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>
<BLOCKQUOTE TYPE=CITE>
<PRE>
If quota management and storage are
completely encapsulated within dmu, then dmu has to provide full quota
control interface too, and that interface has to be exported from osd
upward. For one thing, implementation of this interface is going to take
a lot of time.
</PRE>
</BLOCKQUOTE>
<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>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> For things that requires knowledge of DMU internals (like space
> accounting, spacemaps, ...) it shouldn't be the DMU consumer that has to
> write during the txg sync phase, it should be the DMU because only the
> DMU should know about its internals.
I don't quite understand this argument. DMU already has an interface to
capture a buffer into a transaction and to modify it within this
transaction. An interface to modify a buffer after transaction was
closed, but before it is committed is no more "internal" than the first
one. It is just places more restrictions on what consumer is allowed to
do with the buffer.
</PRE>
</BLOCKQUOTE>
<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>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
--<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="450">
<TR>
<TD WIDTH="121" VALIGN="top">
<IMG SRC="cid:1212006908.14599.51.camel@localhost" ALIGN="bottom" BORDER="0">
</TD>
<TD WIDTH="329" VALIGN="top">
<B><FONT SIZE="1">Ricardo Manuel Correia</FONT></B><BR>
<FONT SIZE="1">Lustre Engineering</FONT><BR>
<BR>
<B><FONT SIZE="1">Sun Microsystems, Inc.</FONT></B><BR>
<FONT SIZE="1">Portugal</FONT><BR>
<FONT SIZE="1">Phone +351.214134023 / x58723</FONT><BR>
<FONT SIZE="1">Mobile +351.912590825</FONT><BR>
<FONT SIZE="1">Email <A HREF="mailto:Ricardo.M.Correia@Sun.COM">Ricardo.M.Correia@Sun.COM</A></FONT>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>