[LU-3935] lfsck_start ignores -n/--dryrun

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.5.0, Lustre 2.4.2
• Affects Version/s: Lustre 2.4.0
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: Christopher Morrone (Inactive)

Description

Under Lustre 2.4.0, the lctl subcommand lfsck_start ignores the n/-dryrun command. For instance:

lctl lfsck_start --dryrun on -M <MDT name>

That currently results in a real run of the OI scrub, and real modification to the filesystem, directly in contradiction to the documentation.

I can understand if implementing that is going to take more work than we want to spend right now, but until the functionality is implemented the cmomand must return an error. It should not go ahead and make changes.

Further, I am not particularly fond of the "--dryrun on" syntax. Unless there is a really, really good reason that -n and --dryrun need to take on/off options, the command line interface should not be designed this way. I think that -n/--dryrun should be optionless. (If they are present on the command line that means dryrun mode must be enabled.)

That would match most sysadmins' expected behavior. Every other command I think that I have ever seen makes the dryrun command optionless. For instance:

• fsck -N
• rsync -n/--dryrun

Issue Links

• is related to: LU-5110 Interop 2.5.1<->2.6 failure on test suite sanity-scrub test_15: Failed to start OI scrub on mds1
• is related to: LU-4058 Interop 2.4.0<->2.5 failure on test suite sanity-scrub test_15

Comments

[Jodi Levi (Inactive)]

Patch landed to Master so closing ticket. If more work is needed let me know and I will reopen

[nasf (Inactive)]

The patch for dryrun mode OI scrub on master:

http://review.whamcloud.com/#/c/7720/

[Andreas Dilger]

I agree that "--dry-run" should not make any changes to the filesystem, so that should be fixed.

The tricky part is that OI Scrub is supposed to start automatically at mount time to fix a broken/missing OI file in order to repair it promptly.

[nasf (Inactive)]

My current idea for that is

1) If it is pure OI scrub without other LFSCK components scanning, then we should support "--dryrun".

2) If it is a combined running (OI scrub plus others) with "--dryrun" mode, then we should notice up layer LFSCK components to stopped/paused if found inconsistent OI mappings, and rescanning after OI scrub repaired inconsistent OI mappings.

Andreas, what's your suggestion?

[Christopher Morrone (Inactive)]

I don't care how beneficial OI scrub is.

The man page clearly states:

         -n, --dryrun <on|off>
              Perform a trial run with no changes made.

When I used it, there were changes made. That is not acceptable.

So maybe you rename the option to "--dont-do-as-much" and clearly document what it does and does not alter about the scan's behavior.

[nasf (Inactive)]

It is not because of dryrun mode will need more time than expected. The key reason is that inode-table based iteration is a basic infrastructure for other up layer LFSCK components. We allow single LFSCK scanning to verify kinds of system inconsistency (such as OI mapping inconsistency, namespace inconsistency, MDT-OST layout inconsistency, MDT-MDT DNE inconsistency) to improve the efficiency. That is important for a very large system. If we does not fix the found OI mappings inconsistency during OI scrub, then other up layer LFSCK components will get invalid objects via the wrong OI mappings. Such invalidation may cannot be aware by up layer LFSCK components in time, as to cause some strange behaviour, and even incorrect reparation (or to be repaired).

So it is NOT the "--dryrun" does not work, it works on up layer LFSCK components, such as "lctl lfsck_start -M <MDT-device> -t namespace".

[Peter Jones]

Fan Yong

Could you please comment on this one?

thanks

Peter