[LU-2681] need to handle lsr_flags having other flags set

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Fix Version/s: Lustre 2.4.0
• Type: Technical task
• Priority: Blocker
• Reporter: Andreas Dilger
• Assignee: Di Wang
• Resolution: Fixed
• Labels: MB

Description

The "lsr_flags" field is currently treated as if it only held LU_SEQ_RANGE_MDT or LU_SEQ_RANGE_OST values. These cannot purely be treated as flags, since LU_SEQ_RANGE_MDT = 0 for compatibility reasons.

If the lsr_flags field ever gets other flags in the future, then checks using "==" instead of "&" will fail, for example:

lustre/osd-zfs/osd_oi.c:266

       if (range->lsr_flags == LU_SEQ_RANGE_OST)

A similar "==" check is made in fld_server_lookup().

Probably an LU_SEQ_RANGE_TYPE = 1 mask should be created, and then helper function can be created to check the type:

unsigned fld_range_type(struct lu_seq_range *range)
{
         return range->lsr_flags & LU_SEQ_RANGE_TYPE;
}

and it can be used like:

        if (fld_range_type(range) == LU_SEQ_RANGE_OST)
or
        if (fld_range_type(range) == LU_SEQ_RANGE_MDT)
or
        if (fld_range_type(erange) == fld_range_type(range))

Comments

[Di Wang]

http://review.whamcloud.com/5589

[Andreas Dilger]

Di, to confirm, is the change for LU_SEQ_RANGE_ALL (or LU_SEQ_RANGE_ANY) part of the wire protocol, or is this only for local FLD queries?

[Di Wang]

This is part of wire protocol, client seq check will also need pack this RANGE_ALL(RANGE_ANY)flags.

[Andreas Dilger]

New version of patch is at http://review.whamcloud.com/5999, 5589 is abandoned.

[Peter Jones]

Landed for 2.4