[LU-3357] lctl replace_nids loses Target UUID from llog header Created: 20/May/13  Updated: 11/Jul/13  Resolved: 11/Jul/13

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.4.0
Fix Version/s: Lustre 2.5.0

Type: Bug Priority: Critical
Reporter: Nathaniel Clark Assignee: Nathaniel Clark
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocker
is blocking LU-2200 Test failure on test suite conf-sanit... Resolved
Severity: 3
Rank (Obsolete): 8313

 Description   

This is reproducible using master (circa tag 2.4.50)

Prior to replace nids:

[root@lumgr1 CONFIGS]# llog_reader t32fs-client
Header size : 8192
Time : Thu Feb  7 22:24:35 2013
Number of records: 35
Target uuid : config_uuid 
-----------------------
...

After remounting w/ nosvc and running:
lctl replace_nids t32fs-OST0000 192.168.139.20@tcp

same log files is now:

Header size : 8192
Time : Mon May 20 09:13:03 2013
Number of records: 35
Target uuid :  
-----------------------
...

The "Target uuid" is also deleted from t32fs-MDT0000.

I used conf-sanity/32 tarball disk2_1-ldiskfs.tar.bz2 as my starting point.



 Comments   
Comment by Nathaniel Clark [ 20/May/13 ]

http://review.whamcloud.com/6395

Comment by Mikhail Pershin [ 21/May/13 ]

I wonder is that so critical to see that UUID? I find it useless, we know already that this is config llog, just because of name. Is it really helpful for something or used by some other tool?

Comment by Nathaniel Clark [ 21/May/13 ]

Mike,

This field doesn't seem to be used too often, but it is checked in the lctl conf_param code path, and if it's not set correctly, the conf_param fails (see llog_init_handle) in MDS debug_log in https://maloo.whamcloud.com/test_sets/8391fe9a-c0cf-11e2-8490-52540035b04c

Comment by Mikhail Pershin [ 21/May/13 ]

OK, got it.

Comment by Nathaniel Clark [ 11/Jul/13 ]

Patch merged to master (post 2.4.51)

Generated at Sat Feb 10 01:33:13 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.