[LU-1997] 'exclude' mount option does not work in lustre b2_1

• Type: Bug
• Resolution: Incomplete
• Priority: Minor
• Environment: rhel6.3
• Severity: 3
• Assignee: Bob Glossman (Inactive)
• Reporter: Diego Moreno (Inactive)

Description

When mounting a lustre client, if we use the 'exclude' option to ignore inactive OSTs this option is not well taken into account.

From the mount.lustre manpage:

exclude=ostlist Start a client or MDT with a (colon-separated) list of known inactive OSTs.

We run the mount command:

[root@berlin105 ~]# mount -t lustre -o user_xattr,exclude=b8-OST0007 60.64.2.84@o2ib0,160.64.2.84@o2ib1:/b8 /b8

In the dmesg we can see the option is seen by lustre:
[root@berlin105 ~]# dmesg
Lustre: MGC60.64.2.84@o2ib: Reactivating import
Lustre: 18527:0:(obd_mount.c:1892:lustre_check_exclusion()) Excluding b8-OST0007 (on exclusion list)
Lustre: Mounted b8-client

But the osc is always up and we can still write or read:
[root@berlin105 ~]# lctl dl | grep b8-OST0007
14 UP osc b8-OST0007-osc-ffff8808773f9c00 6dafd66d-9939-a1d6-cf40-529950167a65 5

Whether the OST is disabled in the MDT or not the problem is always present and we are always accessing this OST from the client. If we try to deactivate the OST with 'lctl --device b8-OST0007-osc-ffff8808773f9c00 deactivate' then the OST is well disabled but never when using exclude option.

Issue Links

• is related to: LU-2200 Test failure on test suite conf-sanity, subtest test_32a

Comments

[John Fuchs-Chesney (Inactive)]

We are marking this as resolved, since b2_1 is no longer active.

~ jfc.

[Bob Glossman (Inactive)]

This failure exists not just in 2.1 but in current master too.

From an example debug log with +info and +config tracing a mount cmd with '-o exclude=lustre-OST0001', it looks like the OST is getting set to inactive initially just like it should:

00000100:00080000:0.0:1348503210.959470:0:27538:0:(pinger.c:425:ptlrpc_pinger_add_import()) adding pingable import 6f04d5c6-cdc4-18e4-1e30-9fc484f77a7f->lustre-OST0001_UUID
00000020:00000040:0.0:1348503210.959472:0:27538:0:(genops.c:957:class_import_get()) import ffff880037e42800 refcount=4 obd=lustre-OST0001-osc-ffff88000f91f400
00020000:01000000:0.0:1348503210.959473:0:27538:0:(lov_obd.c:195:lov_connect_obd()) Connected tgt idx 1 lustre-OST0001_UUID (lustre-OST0001-osc-ffff88000f91f400) inactive

but the effect of this is eliminated a short time later by a lov_set_osc_active():

00000100:00080000:0.0:1348503210.960090:0:27013:0:(import.c:851:ptlrpc_connect_interpret()) connected to replayable target: lustre-OST0001_UUID
00000100:00080000:0.0:1348503210.960091:0:27013:0:(import.c:871:ptlrpc_connect_interpret()) ffff880037e42800 lustre-OST0001_UUID: changing import state from CONNECTING to FULL
00020000:00000040:0.0:1348503210.960092:0:27013:0:(lov_obd.c:392:lov_set_osc_active()) Searching in lov ffff880005a3a758 for uuid lustre-OST0001_UUID event(2)
00020000:00000040:0.0:1348503210.960092:0:27013:0:(lov_obd.c:402:lov_set_osc_active()) lov idx 0 is lustre-OST0000_UUID conn 0x3bc31bbe07ddca6f
00020000:00000040:0.0:1348503210.960093:0:27013:0:(lov_obd.c:402:lov_set_osc_active()) lov idx 1 is lustre-OST0001_UUID conn 0x3bc31bbe07ddca76
00020000:01000000:0.0:1348503210.960094:0:27013:0:(lov_obd.c:431:lov_set_osc_active()) Marking OSC lustre-OST0001_UUID active

I'm not sure why the inactive state doesn't persist.

[Peter Jones]

Bob

Could you please look into this one?

Thanks

Peter