[LU-3006] failover nids added after format don't propogate to clients

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.4.0
• Affects Version/s: Lustre 2.4.0
• Labels: MB
• Environment: Lustre 2.3.61 server. The lack of failover nids in the osc imports field also happens on 1.8 clients so it is a server side issue.
• Severity: 3
• Assignee: Alex Zhuravlev
• Reporter: James A Simmons

Description

While preparing for our test shot after we formatted the new file system we remembered to add the failover nids for IR testing. So we umounted the file system and used tunefs.lustre to add the failover nids. Then proceeded remount the file system in order of MGS, MDT, then serially the OSTs. After mounting a client to validate that the proper failover nids toke hold we discovered that in the osc imports failover nids were never updated. So with a second try we ran tunefs.lustre to remove the failover nids. Then started and stopped the file system. Added the failover nids with tunefs.lustre and then restarted the file system the second time. Again lctl get_param osc-*..../import | grep failover_nids did not show the failover nids getting updated.

Issue Links

• is related to: LU-3352 conf-sanity test_73: failover nids haven't changed
• is related to: LU-3167 The MDT volume label tokenizer is not consistent
• is related to: LU-3244 Test failure on test suite conf-sanity, subtest test_73: failure to start ost

Comments

[Alex Zhuravlev]

landed

[Alex Zhuravlev]

not a final one, but the idea was to search for another place in the superblock to store the flag. working on this...

[Andreas Dilger]

Alex, did we come up with a solution to this problem? This is one of the more noticeable regressions in 2.4.0 for end users.

[Andreas Dilger]

Alex, I'm not a big fan of abusing the label for an increasing number of different flag meanings. The main problem is that this permanently changes the target name that is visible to applications, and there are times when it is not reset. For example, this would prevent the filesystem from being mounted by label after a reboot.

Is there no other field we can use to pass information to the MGS?

[Alex Zhuravlev]

http://review.whamcloud.com/5982

[James A Simmons]

As long as it preserves previous behavior it sounds reasonable. Looking forward to a patch for this.

[Alex Zhuravlev]

I'm tempted to introduce another delimiter in the label to store UPDATE.. should be enough and trivial to implement. any thoughts?

[Peter Jones]

As per Oleg, Alex is thinking about how to address this

[Jason Hill (Inactive)]

Alex Zhuravlev Mar 29

Patch Set 1: I would prefer that you didn't submit this

(1 inline comment)

given UPDATE is not cleared upon mount, we would lead to rewriting a profile on every mount.. i don't think this is good. we need to decide whether we need to modify mountdata to clear UPDATE flag as we were doing previously or we disable this functionality in tunefs.

So as I understand it this patch isn't going to be accepted and the tunefs.lustre syntax for setting failover nids will not be supported moving forward, correct? Was this a purposeful change? Where is the documentation update for this – it is not reflected in the current lustre 2.4 (see section 30.1.3 for MDS failover 36.18.3 for tunefs.lustre options documentation). Will this be updated and announced? This is a major shift from previous versions – and has not been discussed at length. I know Andreas has talked a lot about the tuneables in /proc not being settable via command line but this is far different from that scenario.

[Zhenyu Xu]

I think it is normal, the failover nid lists all service nids, the first one is the preferable one.