<!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 Qua, 2008-05-28 at 20:22 +0400, Nikita Danilov wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Even doing it internally looks rather involved. The problem, as I
understand it, is that no new block can be allocated while transaction
group is in sync state (?)
</PRE>
</BLOCKQUOTE>
<BR>
I'm not sure if you are describing it incorrectly or just using the same terms for different concepts, but in any case, blocks are allocated *while* the transaction group is syncing, and due to compression and online pool configuration changes it is impossible to know the exact on-disk space a given block will use until the transaction group is actually syncing.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
so DMU would have to track all users and
groups whose quota is affected by the current transaction group, and
before closing the group, to allocate some kind of on-disk table with an
entry for every updated quota, then to fill these entries later when
actual disk space is allocated.
</PRE>
</BLOCKQUOTE>
<BR>
Yes, that sounds correct.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Note that dmu has to know about users and groups to implement quota
internally, which looks like a pervasive interface change.
</PRE>
</BLOCKQUOTE>
<BR>
No, AFAIK, the consensus we reached with the ZFS team is that, since the DMU does not have any concept of users or groups, it will track space usage associated with opaque identifiers, so that when we write to a file we would give it 2 identifiers which, for us, one of them would map to a user and the other one to a group.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
I absolutely agree that DMU has to do space _accounting_ internally. The
question is how to store results of this accounting, without bothering
DMU with higher level concepts such as a user or a group identifier.
</PRE>
</BLOCKQUOTE>
<BR>
I really don't think we should allow the consumer to write to a txg which is already in the syncing phase, I think the DMU should store the accounting itself.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
I think that utility of DMU as a universal back-end would improve if it
were to export an interface allowing its users to update, with certain
restrictions, on-disk state when transaction group is in sync (i.e.,
interface similar to one that is internally used for spacemaps).
</PRE>
</BLOCKQUOTE>
<PRE>
</PRE>
Hmm.. I'm not sure if that would be very useful, why not write the data when the txg was open in the first place? Maybe you can give a better example?<BR>
<BR>
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.<BR>
<BR>
The example you have given (spacemaps) is the worst of all, because spacemap updates are rather involved. Due to COW and to the ZIO pipeline design, spacemap modifications lead to a chicken-and-egg problem with transactional updates:<BR>
<BR>
When you modify a space map, you create a ZIO which just before writing leads to an allocation (due to COW). But since you need to do an allocation, you need to change the spacemap again, which leads to another allocation (and also leads to free the old just-written block), so you need to update the space map again, and so on and on.. (!)<BR>
This is why txgs need to converge and why after a few phases it gives up freeing blocks, and starts re-using blocks which were freed on the same txg.<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:1211992969.14599.0.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>