Heiko Schroeter
2009-Jan-27 09:28 UTC
[Lustre-discuss] lctl does not show inactive status OST on client
Hello,
after deactivating an OST on the MDS with
mds1 ~ # lctl --device 11 conf_param foo-OST0006.osc.active=0
lctl on the mds does mark it as inactive
mds1 ~ # lctl dl
0 UP mgs MGS MGS 19
1 UP mgc MGC192.168.16.124 at tcp bd6b1e83-d312-7501-7196-8db675caa078 5
2 UP mdt MDS MDS_uuid 3
3 UP lov foo-mdtlov foo-mdtlov_UUID 4
4 UP mds foo-MDT0000 foo-MDT0000_UUID 7
<snip>
11 IN osc foo-OST0006-osc foo-mdtlov_UUID 5
<snap>
On the client it is still marked as ''UP''
cluster1 ~ # lctl dl
0 UP mgc MGC192.168.16.122 at tcp c0493aeb-43e3-136e-879c-148ac9dcdfa9 5
<snip>
8 UP osc foo-OST0005-osc-xxx 5
9 UP osc foo-OST0006-osc-xxx 4
<snap>
(What i can see on the client is the ''4'' at the end of the
lctl line instead
of ''5''.)
but it is marked as inactive here
cluster1 ~ # cat /proc/fs/lustre/osc/foo-OST0006-xxx/active
0
In the messages i get this when lustre gets mounted:
<snip>
Jan 27 10:22:34 cluster1 LustreError: 17602:0:
(lov_obd.c:316:lov_connect_obd()) not connecting OSC foo-OST0006_UUID;
administratively disabled
Jan 27 10:22:34 cluster1 LustreError: 17602:0:
(lov_obd.c:316:lov_connect_obd()) Skipped 5 previous similar messages
Jan 27 10:22:34 cluster1 Lustre: Client foo-client has started
<snap>
From previous discussions i would expect that ''lctl conf_param
...'' would
deactivate the OST for the whole lustre system and not just for the MDS in
contrast to ''lctl set_param .... '', which does just that for
the MDS only.
Deactivating the OST on a client, as suggested in a Mail ("lctl deactivate
questions") in the Mailing List from 5th Feb 2008, does not change a thing.
It would be convenient that permanently deactivated OSTs would be listed
as ''IN'' on all nodes.
The deactivated OST has been removed and will never be used again in the
lustre system. We do not have problems with sparsing the numbering of the
OSTs if an OST is permanently removed.
lustre 1.6.6, vanilla kernel x86_64 2.6.22.19 with lustre patches.
Thanks and Regards
Heiko
Heiko Schroeter
2009-Jan-30 12:13 UTC
[Lustre-discuss] lctl does not show inactive status OST on client
Any idea ? Regards Heiko Hello, after deactivating an OST on the MDS with mds1 ~ # lctl --device 11 conf_param foo-OST0006.osc.active=0 lctl on the mds does mark it as inactive mds1 ~ # lctl dl 0 UP mgs MGS MGS 19 1 UP mgc MGC192.168.16.124 at tcp bd6b1e83-d312-7501-7196-8db675caa078 5 2 UP mdt MDS MDS_uuid 3 3 UP lov foo-mdtlov foo-mdtlov_UUID 4 4 UP mds foo-MDT0000 foo-MDT0000_UUID 7 <snip> 11 IN osc foo-OST0006-osc foo-mdtlov_UUID 5 <snap> On the client it is still marked as ''UP'' cluster1 ~ # lctl dl 0 UP mgc MGC192.168.16.122 at tcp c0493aeb-43e3-136e-879c-148ac9dcdfa9 5 <snip> 8 UP osc foo-OST0005-osc-xxx 5 9 UP osc foo-OST0006-osc-xxx 4 <snap> (What i can see on the client is the ''4'' at the end of the lctl line instead of ''5''.) but it is marked as inactive here cluster1 ~ # cat /proc/fs/lustre/osc/foo-OST0006-xxx/active 0 In the messages i get this when lustre gets mounted: <snip> Jan 27 10:22:34 cluster1 LustreError: 17602:0: (lov_obd.c:316:lov_connect_obd()) not connecting OSC foo-OST0006_UUID; administratively disabled Jan 27 10:22:34 cluster1 LustreError: 17602:0: (lov_obd.c:316:lov_connect_obd()) Skipped 5 previous similar messages Jan 27 10:22:34 cluster1 Lustre: Client foo-client has started <snap>>From previous discussions i would expect that ''lctl conf_param ...'' woulddeactivate the OST for the whole lustre system and not just for the MDS in contrast to ''lctl set_param .... '', which does just that for the MDS only. Deactivating the OST on a client, as suggested in a Mail ("lctl deactivate questions") in the Mailing List from 5th Feb 2008, does not change a thing. It would be convenient that permanently deactivated OSTs would be listed as ''IN'' on all nodes. The deactivated OST has been removed and will never be used again in the lustre system. We do not have problems with sparsing the numbering of the OSTs if an OST is permanently removed. lustre 1.6.6, vanilla kernel x86_64 2.6.22.19 with lustre patches. Thanks and Regards Heiko _______________________________________________ Lustre-discuss mailing list Lustre-discuss at lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss