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
(From update of attachment 9300)>+#define LLOG_MAX_CFG_SIZE 216 /* largest cfg record size */
Is there a reason you picked this, or would it be better to pick a size that
fits evenly into a 4kB or 8kB block? Or is that the case after the header and
tail are added?
>+ if (class_match_param(ptr,
PARAM_OSC""PARAM_ACTIVE, &tmp) == 0){
Just curious, do you actually need the "", or is it fine just to use a
space
here? I think adjacent strings are concatenated by default and the CPP
doesn''t
really distinguish between literal strings and those in a #define.
>@@ -267,15 +267,15 @@ int llog_process(struct llog_handle *log
>
> CDEBUG(D_OTHER, "after swabbing, type:
%#x\n",
> rec->lrh_type);
>-
>+
Please try to avoid adding whitespace at the end of lines (/ $/ is a good
regexp for that, or if you use vim you can use "let c_space_errors=1"
in
.vimrc).
>@@ -275,6 +297,8 @@ static struct lprocfs_vars lprocfs_obd_v
> //{ "filegroups", lprocfs_rd_filegroups, 0, 0 },
> { "ost_server_uuid", lprocfs_rd_server_uuid, 0, 0 },
> { "ost_conn_uuid", lprocfs_rd_conn_uuid, 0, 0 },
>+ { "active", lprocfs_rd_server_uuid,
>+ osc_wr_active, 0 },
Is this correct that you want to read the server UUID from this instead of the
current active state? Cut-n-paste error?
>@@ -360,19 +381,23 @@ void print_records(struct llog_rec_hdr *
>+ if (recs[i]->padding == 0x678)
>+ printf("NOT SET ");
I don''t understand this.
I don''t have any objection to the code itself, but maybe you can
explain a bit
better why it is hard to find the config records in the llog?
Is it a matter of how long it might take to search for them? Note that there
is existing code in CVS HEAD for finding particular record indices efficiently.
The llog structure allows skipping whole blocks (by calculating the minimum
offset of a particular index based on the minimum record size), and we could
even track the "average" record size if we wanted because we can
always do
backward record walking using the size in the tail of the record if we
overshoot.
I do agree that making a fixed-size record could bite us in the ass later (we
had almost 8kB records for the LOV config before they were split into
individual records).