https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5231 Lustre <p>While archiving a 5GiB file on a client:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># ls -l bigf -rw-r--r-- 1 root root 5129887744 Jun 18 16:48 bigf # lfs hsm_archive bigf </pre> </div></div> <p>I repeatedly checked the progress with lfs hsm_action:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>bigf: ARCHIVE running (0xa00000 bytes moved) ... bigf: ARCHIVE running (0x3200000 bytes moved) ... bigf: ARCHIVE running (0x6400000 bytes moved) ... ... ... bigf: ARCHIVE running (0x1a0e500000 bytes moved) ... bigf: NOOP </pre> </div></div> <p>The last result should have been close to 5 GiB, instead it was 0x1a0e500000 = 111909273600 = 104GiB</p> <p>It appears the (correct) lengths sent by the copytool through llapi_hsm_action_progress() are being added somewhere in the kernel modules.</p> <p>Also, is there a reason for the reported size to be written in hex? It's not convenient.</p> Centos 6.5<br/> Lustre 2.5.56 LU-5231

HSM: incorrect progress reported by lfs hsm_action

Bug Minor Reopened Unresolved WC Triage Frank Zago HSM patch Wed, 18 Jun 2014 22:00:55 +0000 Thu, 3 Sep 2015 19:02:38 +0000 Lustre 2.6.0 0 12 <p>copytool is standard posix copytool.</p> <p>Posted changes for fixing this issue on b2_6</p> <p><a href="http://review.whamcloud.com/12006" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12006</a></p> <p>Vinayak</p> <p>Could you please push your proposed patch against master?</p> <p>Thanks</p> <p>Peter</p> <p>Hi Peter,</p> <p>Pushed the changes to master branch.<br/> <a href="http://review.whamcloud.com/12020" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12020</a></p> <p>Thanks,<br/> Vinayak</p> <p>Please observe the comments and kernel logs below.<br/> Looking at these logs, I strongly feel that last extent alone will give proper amount of data moved. <br/> Logs are taken in steps. Please observe the data-&gt;done_size in each step (numbered as 1, 2, 3....). <br/> The values are repeating in each step which means whenever the ioctl is performed, the extents are <br/> getting stored in tree. I believe we should not add up all these extents and the last entry in the <br/> tree (last extent) will alone give the total amount of data moved.</p> <p>frank zago (fzago@cray.com) uploaded a new patch: <a href="http://review.whamcloud.com/13678" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13678</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5231" title="HSM: incorrect progress reported by lfs hsm_action" class="issue-link" data-issue-key="LU-5231">LU-5231</a> hsm: display file size in decimal not hex<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 1f8c980d4cd2328936e9dd484909c62a4a5fd8cc</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/13678/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13678/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5231" title="HSM: incorrect progress reported by lfs hsm_action" class="issue-link" data-issue-key="LU-5231">LU-5231</a> hsm: display file size in decimal not hex<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 9e40a86a875475f3fe1991a48694ba5601033ebe</p> <p>Landed for 2.8</p> <p>I'm not sure why this ticket was marked resolved when <a href="http://review.whamcloud.com/12020" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12020</a> is still pending.</p> <p>My overzealousness I'm afraid - sorry. Reopening</p> Development Rank 1|hzwpev: Rank (Obsolete) 14572 Severity