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-9187 Lustre <p>Current implementation does not properly handle the LFSCK parameter "failout" and "dryrun", as to it only works for OI scrub, but does NOT work for namespace LFSCK and layout LFSCK.</p> LU-9187

LFSCK needs to handle parameter "failout" and "dryrun" properly

Bug Critical Resolved Fixed nasf nasf Tue, 7 Mar 2017 06:36:47 +0000 Tue, 23 May 2017 16:19:59 +0000 Tue, 9 May 2017 17:31:21 +0000 Lustre 2.10.0 0 6 <p>Fan Yong (fan.yong@intel.com) uploaded a new patch: <a href="https://review.whamcloud.com/25849" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/25849</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9187" title="LFSCK needs to handle parameter &quot;failout&quot; and &quot;dryrun&quot; properly" class="issue-link" data-issue-key="LU-9187"><del>LU-9187</del></a> lfsck: handle parameters properly<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: b2a84a3bf8a9dc68616e5a6db65d483e28d349aa</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/25849/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/25849/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9187" title="LFSCK needs to handle parameter &quot;failout&quot; and &quot;dryrun&quot; properly" class="issue-link" data-issue-key="LU-9187"><del>LU-9187</del></a> lfsck: handle parameters properly<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 03ab4771dfc6dafa8e6cd72509d8a6ac6c7046da</p> <p>The last dry run for LFSCK on our atlas production systems completed, but we are still seeing that there were entries that were fixed even though we have the “dryrun” patch (see output below). So the patch that landed for <a href="https://jira.whamcloud.com/browse/LU-9187" title="LFSCK needs to handle parameter &quot;failout&quot; and &quot;dryrun&quot; properly" class="issue-link" data-issue-key="LU-9187"><del>LU-9187</del></a> only partially fixed the issue.</p> <p>Also, it looks like no debug data could be captured for the lfsck output using the debug buffer even though lfsck output was configured to be captured. I don’t think we overwrote The debug buffer was not overwritten because the dump file was only 3.1 MB and the buffer was set to hold 721MB before overwriting (see output below). It would like to at a minimum get output of what was fixed even if we can’t run in dryrun mode. </p> <p><span class="error">&#91;output&#93;</span><br/> name: lfsck_namespace<br/> magic: 0xa0621a0b<br/> version: 2<br/> status: completed<br/> flags: inconsistent<br/> param: dryrun,all_targets,orphan<br/> last_completed_time: 1493374063<br/> time_since_last_completed: 3809 seconds<br/> latest_start_time: 1493035314<br/> time_since_latest_start: 342558 seconds<br/> last_checkpoint_time: 1493374063<br/> time_since_last_checkpoint: 3809 seconds<br/> latest_start_position: 77, N/A, N/A<br/> last_checkpoint_position: 1073740039, N/A, N/A<br/> first_failure_position: 930672790, N/A, N/A<br/> checked_phase1: 468966333<br/> checked_phase2: 272516<br/> updated_phase1: 1<br/> updated_phase2: 0<br/> failed_phase1: 0<br/> failed_phase2: 14<br/> directories: 66928508<br/> dirent_repaired: 0<br/> linkea_repaired: 1<br/> nlinks_repaired: 0<br/> multiple_linked_checked: 547668<br/> multiple_linked_repaired: 0<br/> unknown_inconsistency: 0<br/> unmatched_pairs_repaired: 0<br/> dangling_repaired: 0<br/> multiple_referenced_repaired: 0<br/> bad_file_type_repaired: 0<br/> lost_dirent_repaired: 0<br/> local_lost_found_scanned: 0<br/> local_lost_found_moved: 0<br/> local_lost_found_skipped: 0<br/> local_lost_found_failed: 0<br/> striped_dirs_scanned: 0<br/> striped_dirs_repaired: 0<br/> striped_dirs_failed: 0<br/> striped_dirs_disabled: 0<br/> striped_dirs_skipped: 0<br/> striped_shards_scanned: 0<br/> striped_shards_repaired: 0<br/> striped_shards_failed: 0<br/> striped_shards_skipped: 0<br/> name_hash_repaired: 0<br/> linkea_overflow_cleared: 0<br/> success_count: 3<br/> run_time_phase1: 338639 seconds<br/> run_time_phase2: 102 seconds<br/> average_speed_phase1: 1384 items/sec<br/> average_speed_phase2: 2671 objs/sec<br/> average_speed_total: 1385 items/sec<br/> real_time_speed_phase1: N/A<br/> real_time_speed_phase2: N/A<br/> current_position: N/A</p> <p>We have the dumps if you want them as well.</p> <p>Under the 'dryrun' mode, the "fixed" items in the LFSCK output does not means real fix, instead, it means the found inconsistent items. You can verify whether the inconsistency has been fixed or not via another dryrun mode LFSCK. If the inconsistency has been fixed in the first dryrun LFSCK, it should NOT be found again during the second dyrun LFSCK.</p> <p>I think it would be more clear for users if "repaired" only indicated actual fixed items, and there be a separate field accounting the errors found. That should probably be a separate ticket. </p> <p>It sounds like any remaining work will be tracked under a new ticket</p> Related LU-9548 LU-9545 Development Rank 1|hzz5yv: Rank (Obsolete) 9223372036854775807 Severity