Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=11229
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|bugs@clusterfs.com |nathan@clusterfs.com
Created an attachment (id=9212)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
--> (https://bugzilla.lustre.org/attachment.cgi?id=9212&action=view)
add ability to change marker records, and deactivate osc''s via proc
add ability to change marker records for permanent deactivation, and deactivate
osc''s via proc for deactivation of all of an OST''s
osc''s in a live cluster.
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=11229
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9212 is|0 |1
obsolete| |
Created an attachment (id=9221)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
--> (https://bugzilla.lustre.org/attachment.cgi?id=9221&action=view)
permanent osc (de)activation, true config param changing
Cancel old parameter settings in config logs, instead of just overwriting old
settings. This allows the permanent deactivation and subsequent (permanent)
reactivation of an osc without the toggling of the active state during
subsequent client startups (when the entire config log is parsed). It also
adds
the .../osc/active writable proc file to change/view the active setting.
Permanent removal of an OST is now accomplished with e.g.:
lctl conf_param lustre-OST0001.osc.active=0
which both sets the appropriate OSC''s inactive on all clients (and
MDT), and
changes the config logs so that newly-starting clients will start with the osc
in the inactive state. If the OST is fixed at some point in the future,
re-enable with active=1.
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=11229
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9221 is|0 |1
obsolete| |
Created an attachment (id=9229)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
--> (https://bugzilla.lustre.org/attachment.cgi?id=9229&action=view)
above plus regression tests
Added regression tests for deactivation and general permanent param changes.
One limitation reveals itself: if we have started a client/MDT with a
particular
OST deactivated, we must restart the client/MDT after reactivation (because a
reactivation (currently) won''t make an initial connection - it will
remain in
DISCONN or NEW state).
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by using the following link: https://bugzilla.lustre.org/show_bug.cgi?id=11229 Created an attachment (id=9299) Please don''t reply to lustre-devel. Instead, comment in Bugzilla by using the following link: --> (https://bugzilla.lustre.org/attachment.cgi?id=9299&action=view) fix for llogs > LLOG_CHUNK_SIZE Sadly, I can''t keep track of the file offset in the llog callback because it''s not called for the padding records across LLOG_CHUNK_SIZE boundaries. So this is an extensive reworking of the original patch (to be applied on top of the old one) to use fixed-size records in the config logs. Plus a new regression test for the big-llog case.
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=11229
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9229 is|0 |1
obsolete| |
Attachment #9299 is|0 |1
obsolete| |
Created an attachment (id=9300)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
--> (https://bugzilla.lustre.org/attachment.cgi?id=9300&action=view)
combined 9229 and 9299
combined above into a single patch for easier review