Mike, you&#39;re right, only rename needs to use the new version of changelog format; and<div>it will be unpacked in liblustreapi, the user space tool will not even notice it.<br><br><div class="gmail_quote">On Thu, Apr 26, 2012 at 2:06 AM, Mikhail Pershin <span dir="ltr">&lt;<a href="mailto:mike.tappro@gmail.com">mike.tappro@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 25 Apr 2012 20:36:08 +0400, Nathan Rutman &lt;<a href="mailto:Nathan_Rutman@xyratex.com" target="_blank">Nathan_Rutman@xyratex.com</a>&gt; wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it wasn&#39;t done that way in the first place because the record size in an llog is fixed,<br>
so any size increase is multiplied by the number of records, so fewer records<br>
can be stored. Splitting the rename into two was the unfortunate casualty of that goal.<br>
</blockquote>
<br></div>
This is true if we are using the same record for all operations and Lai did so by adding extra field. But I&#39;d note that fixed size is not mandatory thing but good to have. Moreover, changelog records are naturally not fixed size because contain name which size is not fixed. So I suppose rename was done in two parts just as simpler way to go because required no additional changes in processing, etc. Also, IIRC, CL_EXT appeared even later than CL_RENAME itself.<br>

<br>
To avoid space consuming we can just introduce extended &#39;changelog_ext_rec&#39; for rename. It is not the problem to create such changelogs but requires processing tools to be aware about that, is that a big problem or acceptable?<div class="HOEnZb">
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Apr 25, 2012, at 2:05 AM, Lai Siyao wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rename record in Changelog is different from other operations, it&#39;s split into<br>
two records: RNMFRM and RNMTO. This makes Changelog analysis hard<br>
because these two records may not be consecutive and several renames<br>
may occur at the same time.<br>
<br>
I&#39;m not clear why it&#39;s designed to be so, except that RNMTO is needed<br>
because for DNE (distributed namespace) the rename target may reside on<br>
another MDS, and a separate RNMTO record is needed. But even with this<br>
it&#39;s fine to store all information in a RENME record, but leave the information of<br>
whether rename removes the last hardlink of the target file (if it exists) in<br>
RNMTO record.<br>
<br>
I tried to add a field spfid in struct changelog_rec to store source parent fid,<br>
and pack both source (if has) and target names into record. Normally the<br>
record size if sizeof(fid) larger than before, and it can be differentiated<br>
according to version. The test result looks good, but I want to know whether<br>
anyone oppose to this? If not, I&#39;ll make the change and make it changelog<br>
version 2.<br>
<br>
Cheers,<br>
- Lai<br>
<br>
<br>
______________________________<u></u>_________________<br>
Lustre-devel mailing list<br>
<a href="mailto:Lustre-devel@lists.lustre.org" target="_blank">Lustre-devel@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-devel" target="_blank">http://lists.lustre.org/<u></u>mailman/listinfo/lustre-devel</a><br>
</blockquote>
______________________________<u></u>_________________<br>
Lustre-devel mailing list<br>
<a href="mailto:Lustre-devel@lists.lustre.org" target="_blank">Lustre-devel@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-devel" target="_blank">http://lists.lustre.org/<u></u>mailman/listinfo/lustre-devel</a><br>
</blockquote>
</div></div></blockquote></div><br></div>