<!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 Sáb, 2008-05-31 at 20:19 +0400, Nikita Danilov wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
I meant a counter of bytes or blocks that this object occupies for the
quota purposes. I specifically don't want to identify `space usage' with
st_blocks, because for the modern file systems there is no _the_ way to
define what to include into quota: users want quota to be consistent
with both df(1) and du(1) and in the presence of features like snapshots
this is not generally possible.
</PRE>
</BLOCKQUOTE>
<BR>
I think dnode_phys_t->dn_used can be used for this, because AFAICS it keeps track of allocated space referenced by the active filesystem (in other words, it does not include space which is referenced only by snapshots).<BR>
<BR>
I am assuming snapshots should not have any effect on quotas, right?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> group N+1 may already be quiescing. This presents a challenge because if
> the machines crashes, you may lose data in 2 transaction groups, not
> just 1, which I think would make things harder to recover..
Won't it be enough to record in the pending list object from two last
transaction groups, if necessary?
</PRE>
</BLOCKQUOTE>
<BR>
Hmm.. I think so, but I think we should not rely on this always being 2, I think we should allow the list to have an unbounded size, and let the commit callbacks notify when an entry can be pruned from the list.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
But we don't have to, if we make ->space_usage() idempotent, i.e.,
taking an absolute space usage as a last argument, rather than delta. In
that case, DMU is free to call it multiple times, and client has to cope
with this. (Hmm... I am pretty sure this is what I was thinking about
when composing previous message, but confusing signed __s64 delta
somehow got in, sorry.)
</PRE>
</BLOCKQUOTE>
<BR>
Ok, that clears my previous concern.<BR>
But in this case, how do you know how much you need to add or subtract to a quota when an object changes size?<BR>
I am guessing that you'd need to at least write the previous object size as part of the pending list, so that when you're recovering you'd know the delta..<BR>
<BR>
Heh, to me this whole thing sounds quite complicated to get right, but I think it could work (but of course, fine-grained hard quotas is another matter altogether..)..<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> And furthermore, I think this kind of recovery could be better
> implemented using commit callbacks, which is an abstraction already
> designed for recovery purposes and which is backend-agnostic.
Sounds interesting, can you elaborate on this?
</PRE>
</BLOCKQUOTE>
<BR>
I was thinking that commit callbacks could be used by the DMU consumer to solve this problem instead of having an internal DMU list/log, and I guess you've already figured out how that could be done :)<BR>
<BR>
Cheers,<BR>
Ricardo<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:1212251874.21348.79.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>