[LU-4294] lctl dl does not show inactive state for deactivated OST Created: 22/Nov/13  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Minor
Reporter: Wolfgang Baudler Assignee: Emoly Liu
Resolution: Duplicate Votes: 0
Labels: server
Environment:

Lustre 2.4.1 RHEL6 2.6.32-358.18.1.el6_lustre.x86_64


Issue Links:
Related
is related to LUDOC-218 update Lustre 2.x manual to reflect O... Open
Severity: 3
Epic: server
Rank (Obsolete): 11778

 Description   

I deactivate an OST with

lctl --device 56 deactivate

56 being the first column number of "lctl dl" output.

After this "lctl dl" still shows the OST as "UP":

56 UP osp vegas-OST0059-osc-MDT0000 vegas-MDT0000-mdtlov_UUID 5

Doing a

cat /proc/fs/lustre/lov/vegas-MDT0000-mdtlov/target_obd

however shows the OST set to INACTIVE:

89: vegas-OST0059_UUID INACTIVE



 Comments   
Comment by Andreas Dilger [ 27/Nov/13 ]

"UP" means the device is configured, it is not the same thing as INACTIVE.

Comment by Roland Laifer [ 17/Dec/13 ]

This seems to have changed between Lustre 1.8 and Lustre 2.x: With Lustre 1.8 "lctl dl" reported "IN".
Therefore, the question is if this change was intended since it might confuse administrators (like me).
Also, if the change was intended the Lustre 2.x manual has to be adapted, e.g. chapter 18.8.3 and chapter 19.1.2.

Comment by Peter Jones [ 16/Jan/14 ]

Emoly

Could you please look into this one?

Thanks

Peter

Comment by Emoly Liu [ 21/Jan/14 ]

I have a check at Lustre 2.x manual and find it does say "lctl dl" reports "IN". But I think the example should be older than b2_4, because since b2_4 OSP has been added to replace OSC connected from MDS.

The following values are part of "lctl dl" from b2_3 and master branch respectively.

b2_3:
 10 UP mdc lustre-MDT0000-mdc-ffff88003c798000 aff4df3d-483c-c37a-bed4-19f17dd103ed 5
 11 UP osc lustre-OST0000-osc-ffff88003c798000 aff4df3d-483c-c37a-bed4-19f17dd103ed 5
 12 UP osc lustre-OST0001-osc-ffff88003c798000 aff4df3d-483c-c37a-bed4-19f17dd103ed 5
 13 UP osc lustre-OST0000-osc-MDT0000 lustre-MDT0000-mdtlov_UUID 5
 14 UP osc lustre-OST0001-osc-MDT0000 lustre-MDT0000-mdtlov_UUID 5
master:
 18 UP mdc lustre-MDT0000-mdc-ffff88002379b800 67d79455-bc1e-4856-d567-68656b793b34 5
 19 UP osc lustre-OST0000-osc-ffff88002379b800 67d79455-bc1e-4856-d567-68656b793b34 5
 20 UP osc lustre-OST0001-osc-ffff88002379b800 67d79455-bc1e-4856-d567-68656b793b34 5
 21 UP osp lustre-OST0000-osc-MDT0000 lustre-MDT0000-mdtlov_UUID 5
 22 UP osp lustre-OST0001-osc-MDT0000 lustre-MDT0000-mdtlov_UUID 5

And the code shows that although OSP can receive de/activated setting by "lctl --device", osp_import_event() doesn't call obd_notify() to update obd_inactive status used by "lctl dl". That's why we didn't see "IN" change by deactivating osp device.

Comment by Roland Laifer [ 23/Jan/14 ]

Since "lctl dl" output has changed in newer Lustre versions this should be reflected in the Lustre 2.x manual. Can you create a documentation bug?

Comment by Emoly Liu [ 23/Jan/14 ]

Yes, LUDOC-218 is created for doc update.

Comment by Peter Jones [ 17/Apr/14 ]

Do I understand correctly that this issue is essentially a duplicate of LUDOC-218?

Comment by Emoly Liu [ 18/Apr/14 ]

Yes, this issue can be marked as a duplicate of LUDOC-218. And in the future if needed, we can file a new ticket to modify OSP code.

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