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-6213 Lustre <p>HSM restore causes some file attributes to change (blocks and maybe ctime). tar detects this and reports "tar: f0: file changed as we read it" and will continue archiving but return 1 on exit. So according to its exit status it has failed but the archive contents are correct.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># echo XXXXXXXXXXXXXXXXXXXXXXXX &gt; f0 # echo ZZZZZZZZZZZZZZZZZZZ &gt; f1 # lfs hsm_archive f0 # lfs hsm_state f0 f0: (0x00000009) exists archived, archive_id:1 # lfs hsm_release f0 # lfs hsm_state f0 f0: (0x0000000d) released exists archived, archive_id:1 # tar -cf /tmp/0.tar f0 f1 tar: f0: file changed as we read it # tar -tvf /tmp/0.tar -rw-r--r-- root/root 25 2015-02-05 10:31 f0 -rw-r--r-- root/root 20 2015-02-05 10:34 f1 # rm f0 f1 # tar -xf /tmp/0.tar # ls -l total 1 -rw-r--r-- 1 root root 25 Feb 5 10:31 f0 -rw-r--r-- 1 root root 20 Feb 5 10:34 f1 # cat f0 XXXXXXXXXXXXXXXXXXXXXXXX # cat f1 ZZZZZZZZZZZZZZZZZZZ </pre> </div></div> LU-6213

'tar -c' returns status 1 if HSM released files were encountered

Bug Minor Resolved Fixed John Hammond John Hammond hsm Thu, 5 Feb 2015 16:40:50 +0000 Wed, 26 Aug 2015 17:44:30 +0000 Wed, 26 Aug 2015 17:44:30 +0000 Lustre 2.7.0 Lustre 2.8.0 0 9 <p>It definitely makes sense to keep the previous timestamps when restoring a file. IMHO the userspace visible attributed of the file should stay constant regardless of whether the file is released or restored. </p> <p>Is the timestamp change a side effect of the MDS clock leaking into file attributes, and will this be fixed by other patches in that area?</p> <p>AFAICT, restore is not changing the timestamps, just the blocks. </p> <p>It's the ctime change that tar is reacting to.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">if</span> (ok) { <span class="code-keyword">if</span> ((timespec_cmp (get_stat_ctime(&amp;final_stat), original_ctime) != 0 /* Original ctime will change <span class="code-keyword">if</span> the file is a directory and --remove-files is given */ &amp;&amp; !(remove_files_option &amp;&amp; is_dir)) || original_size &lt; final_stat.st_size) { WARNOPT(WARN_FILE_CHANGED, (0, 0, _(<span class="code-quote">"%s: file changed as we read it"</span>), quotearg_colon(p))); set_exit_status(TAREXIT_DIFFERS); } <span class="code-keyword">else</span> <span class="code-keyword">if</span> (atime_preserve_option == replace_atime_preserve &amp;&amp; set_file_atime(fd, p, restore_times) != 0) utime_error(p); } </pre> </div></div> <p>By skewing clocks I can see that the ctime comes from the copytool node via the OST object from the volatile file. (This is a different file from above.)</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>t3:lustre# echo XXX &gt; f0 t3:lustre# stat f0 File: `f0' Size: 4 Blocks: 1 IO Block: 4194304 regular file Device: 2c54f966h/743766374d Inode: 288230393331580931 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-02-05 15:38:58.000000000 -0600 Modify: 2015-02-05 15:38:58.000000000 -0600 Change: 2015-02-05 15:38:58.000000000 -0600 t3:lustre# lfs hsm_archive f0 t3:lustre# lfs hsm_release f0 t3:lustre# stat f0 File: `f0' Size: 4 Blocks: 1 IO Block: 4194304 regular file Device: 2c54f966h/743766374d Inode: 288230393331580931 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-02-05 15:38:58.000000000 -0600 Modify: 2015-02-05 15:38:58.000000000 -0600 Change: 2015-02-05 15:38:58.000000000 -0600 t3:lustre# lfs hsm_restore f0 t3:lustre# stat f0 File: `f0' Size: 4 Blocks: 8 IO Block: 4194304 regular file Device: 2c54f966h/743766374d Inode: 288230393331580931 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-02-05 15:38:58.000000000 -0600 Modify: 2015-02-05 15:38:58.000000000 -0600 Change: 2015-02-06 15:39:40.000000000 -0600 t3:lustre# lfs getstripe f0 f0 lmm_stripe_count: 1 lmm_stripe_size: 1048576 lmm_pattern: 1 lmm_layout_gen: 2 lmm_stripe_offset: 1 obdidx objid objid group 1 2 0x2 0 t0:~# stat /tmp/mnt/ROOT/f0 File: `/tmp/mnt/ROOT/f0' Size: 4 Blocks: 0 IO Block: 4096 regular file Device: 701h/1793d Inode: 141 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-02-05 15:38:58.000000000 -0600 Modify: 2015-02-05 15:38:58.000000000 -0600 Change: 2015-02-05 15:38:58.000000000 -0600 t2:~# stat /tmp/mnt/O/0/d2/2 File: `/tmp/mnt/O/0/d2/2' Size: 4 Blocks: 8 IO Block: 4096 regular file Device: 707h/1799d Inode: 222 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-02-05 15:38:58.000000000 -0600 Modify: 2015-02-05 15:38:58.000000000 -0600 Change: 2015-02-06 15:39:40.000000000 -0600 </pre> </div></div> <p>John L. Hammond (john.hammond@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/13665" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13665</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6213" title="&#39;tar -c&#39; returns status 1 if HSM released files were encountered" class="issue-link" data-issue-key="LU-6213"><del>LU-6213</del></a> llite: add LL_IOC_FUTIMES_3<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 3433f3e3da4963d5bbe3c5bf05748bc328bd9023</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/13665/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13665/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6213" title="&#39;tar -c&#39; returns status 1 if HSM released files were encountered" class="issue-link" data-issue-key="LU-6213"><del>LU-6213</del></a> llite: add LL_IOC_FUTIMES_3<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 12e4004656f3019d0195d46de6df94af7452fdf8</p> <p>Landed for 2.8.</p> Development Rank 1|hzx5qv: Rank (Obsolete) 17383 Severity