[LU-9548] No debug info from lctl set_param debug=+lfsck shows up with lfsck dry-run Created: 23/May/17  Updated: 16/Jun/18

Status: Open
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.8.0, Lustre 2.9.0, Lustre 2.10.0
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: James A Simmons Assignee: nasf (Inactive)
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Any server that runs lfsck in dry-run mode.


Issue Links:
Related
is related to LU-9187 LFSCK needs to handle parameter "fail... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

While running lfsck in dry-run mode on our servers we set lctl set_param debug=+lfsck in order to collect debug data to see what files will be impacted by a real lfsck run. The debug logs has zero lfsck debug tracing. This doesn't seem to be correct behavior. We would like to know what repairs would be done before a real lfsck run.



 Comments   
Comment by Peter Jones [ 23/May/17 ]

Fan Yong

Could you please advise with this one?

Thanks

Peter

Comment by James A Simmons [ 23/May/17 ]

Does a tool exist that can create errors at the OSD level so lfsck can be tested?

Comment by nasf (Inactive) [ 13/Jun/17 ]

In theory, if there are inconsistent items detected by LFSCK, then "debug=+lfsck" will show related LFSCK actions, in spite of dryrun mode or not, unless the log is overwritten. To verify that, we can inject some failure stub as sanity-lfsck does. For example, sanity-lfsck test_14 will simulate dangling LOV EA reference case.

Comment by nasf (Inactive) [ 07/Aug/17 ]

James,

Have you tried the LFSCK with some failure injection to simulate the inconsistent cases? Is there still no logs with dryrun mode for that?

Thanks!

Comment by nasf (Inactive) [ 05/Jun/18 ]

simmonsja,

Any further feedback for this ticket?

Comment by James A Simmons [ 05/Jun/18 ]

Sorry I haven't got around to looking into this. Please keep the ticket open for now. I will talk to our admins about what they are looking for exactly.

Generated at Sat Feb 10 02:27:09 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.