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-5895 Lustre <p>Archiving, releasing then migrating leads to a "data version changed during migration":</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># cd /mnt/lustre # cp /usr/bin/zip . # lfs getstripe zip zip lmm_stripe_count: 1 lmm_stripe_size: 1048576 lmm_pattern: 1 lmm_layout_gen: 0 lmm_stripe_offset: 1 obdidx objid objid group 1 2 0x2 0 # lfs hsm_archive zip # lfs hsm_release zip # lfs hsm_state zip zip: (0x0000000d) released exists archived, archive_id:1 # lfs getstripe zip zip lmm_stripe_count: 1 lmm_stripe_size: 1048576 lmm_pattern: 80000001 lmm_layout_gen: 1 lmm_stripe_offset: 0 # lfs migrate -o 0 zip /root/lustre-cleanup/lustre/utils/lfs: zip: data version changed during migration error: migrate: migrate stripe file 'zip' failed </pre> </div></div> <p>I think the file is restored first, then migrated, but its data version is not updated. Which lead to the following questions:</p> <ul> <li>is it correct to force a restore of an archived file when asking for a migrate operation?</li> <li>couldn't the file be restored directly to the proper OST/stripe size, ...?</li> <li>although an error is reported, the file is present and complete, so the operation actually completed properly. What if that was another kind of error? Would we get a data corruption?</li> </ul> head of tree + <a href="https://jira.whamcloud.com/browse/LU-4840" title=" Deadlock when truncating file during lfs migrate" class="issue-link" data-issue-key="LU-4840"><strike>LU-4840</strike></a> LU-5895

lfs: data version changed during migration

Bug Major Open Unresolved Ben Evans Frank Zago patch Mon, 10 Nov 2014 20:38:16 +0000 Wed, 29 May 2019 17:16:42 +0000 Lustre 2.7.0 0 10 <p>After the "failed" migration, getstripes return this:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># lfs getstripe zip zip lmm_stripe_count: 1 lmm_stripe_size: 1048576 lmm_pattern: 1 lmm_layout_gen: 2 lmm_stripe_offset: 0 obdidx objid objid group 0 3 0x3 0 </pre> </div></div> <p>So the file has indeed migrated, and is not the original one simply restored.</p> <p>HSM may not allocate the original OST to restore the file, thus your example can't verify that the migration has completed. Please try to migrate the released file to have 2 stripes and see how it goes.</p> <p>When I archive/restore a file, the objid stays the same. It's not the case here.</p> <p>I'll try with 2 stripes.</p> <p>When I tried migrating to 2 stripes, the file was restored to only one stripe. So that part looks ok actually. That third question is now moot. The first 2 remain.</p> <p>I think the 3rd question is a BUG. I didn't look into the code, but I guess the root cause of this problem is that zero data version was returned for released file, but later after file was restored it saw different data version.</p> <p>The 2nd question is a good one. The question can be refined to support setstripe style of restore operation, in another word, the command `lfs hsm_restore' should be able to override original stripe pattern.</p> <p>I have to question whether it even makes sense to migrate a released file? Maybe this should just become a no-op?</p> <p>Yes, it does sense to skip migration for a released file since there is no data to migrate as far as Lustre is concerned.</p> <p>Frank, would you be able to make a patch to just return 0 (do nothing) if trying to migrate a file that is already released?</p> <p>I missed that message. I'll send a patch.</p> <p>frank zago (fzago@cray.com) uploaded a new patch: <a href="http://review.whamcloud.com/13356" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13356</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5895" title="lfs: data version changed during migration" class="issue-link" data-issue-key="LU-5895">LU-5895</a> lfs: prevent migration of a released file<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 28d3e178ee1a9f98f6c7926b5dafca778e98c4e5</p> <p>I've made lfs return an error if the file has been released. I believe it's better to fail than to mislead the user.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># ./lfs migrate /mnt/lustre/zip /mnt/lustre/zip: can't migrate a file released by HSM error: migrate: migrate stripe file '/mnt/lustre/zip' failed </pre> </div></div> <p>But this patch doesn't completely cover the bad case. For instance what happens if there is a race between a release and migrate operation. If the check for the release bit succeeds, then the migrate operation will happen, and the "data version changed during migration" message will be displayed, but the file will be restored. I don't see a solution for that, but we might be able to live with it.</p> <p>I will update that patch according to Henri's suggestion:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Wouldn't it make sense to migrate released files like this: - Open volatile file with O_LOV_DELAY_CREAT - Assign it the desired stripe - Swap layouts with the released file This is totally untested, but I believe it could work and prevent from having to restore released files for the sole purpose of migrating them. </pre> </div></div> <p>This is however depending on "<a href="https://jira.whamcloud.com/browse/LU-6081" title="hsm: add file migrate support" class="issue-link" data-issue-key="LU-6081">LU-6081</a> user: Introducing llapi_create_volatile_param()", which itself will need "<a href="https://jira.whamcloud.com/browse/LU-5657" title="adding missing man pages for the Lustre user API" class="issue-link" data-issue-key="LU-5657"><del>LU-5657</del></a> allow the use of rst2man to build man pages"</p> <p>I wrote the code for it and a basic test (not pushed). 2 problems:</p> <ul class="alternate" type="square"> <li>llapi_fswap_layouts returns -524, which is not a valid error code. Logs indicate it is coming from cl_get_grouplock() in file.c:1660</li> <li>if I disable the request for a group lock in llapi_fswap_layouts(), then the swap works, but the resulting file size is 0. Maybe there is some other operations to do (like setting the released flag on the volatile before swapping).</li> </ul> Development Rank 1|hzx0lz: Rank (Obsolete) 16474 Severity