[LU-2045] clean up inherited default striping in LOD

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Type: Technical task
• Priority: Minor
• Reporter: Andreas Dilger
• Assignee: Alex Zhuravlev
• Resolution: Fixed

Description

Per discussion in http://review.whamcloud.com/4054, it would be desirable to clean up the handling for inherited/default striping in the LOD code:

Is this default striping written to disk for new directories, or just cached in memory?

Directories without an explicit default striping should get their striping from the current filesystem default values.

To which Alex replied:

I just checked on a live filesystem that if (LOVEA_DELETE_VALUES()) RETURN(0); in lod_store_def_striping() works to do like you said: do not write fs-wide default striping.

I think that non-existing LOVEA is equal to LOVEA storing "current default fs striping". and it's OK to set it to every directory unless the parent has own one? then in lod_store_def_striping() we just skip actual storing.

lod_cache_parent_striping():

if (rc < sizeof(struct lov_user_md)) {
/* don't lookup for non-existing or invalid striping */
lp->ldo_def_striping_set = 0;
lp->ldo_striping_cached = 1;
lp->ldo_def_stripe_size = 0;
lp->ldo_def_stripenr = 0;
lp->ldo_def_stripe_offset = (typeof(v1->lmm_stripe_offset))(-1);
GOTO(unlock, rc = 0);

IOW, the object will be storing an indirect pointer to fs-wide default striping, not some actual one.

currently memory footprint is the same all the time. though I'd agree we could save on this and allocate additional memory for directories with non-default striping only.

This bug is to track the outstanding cleanup.

Comments

[Alex Zhuravlev]

Andreas, let's refresh this a bit.. what specifically you'd like to improve: reduce memory footprint? or rework the code to improve readability ?

[Andreas Dilger]

To be honest, I don't recall how I wanted this to be cleaned up. For now, I'd be happy to get some clear comments where the "default" layout is stored on the directory that this will not be saved to disk in whatever function saves it, and again in that function indicating that default layouts are not saved to disk.

[Alex Zhuravlev]

OK, so during directory creation the rough sequence will be:

lod_ah_init()
lod_cache_parent_striping()
/* don't lookup for non-existing or invalid striping */
lp->ldo_def_striping_set = 0;
lp->ldo_striping_cached = 1;
lp->ldo_def_stripe_size = 0;
lp->ldo_def_stripenr = 0;
lp->ldo_def_stripe_offset = (typeof(v1->lmm_stripe_offset))(-1);
GOTO(unlock, rc = 0);

lod_object_create()
if (S_ISDIR(dt->do_lu.lo_header->loh_attr))
lod_store_def_striping(env, dt, th);
if (LOVEA_DELETE_VALUES(lo->ldo_def_stripe_size, lo->ldo_def_stripenr,
lo->ldo_def_stripe_offset))
RETURN(0);

where
#define LOVEA_DELETE_VALUES(size, count, offset) (size == 0 && count == 0 && \
offset == (typeof(offset))(-1))

so, all directory objects will be getting

{0, 0, -1}

striping in struct lod_object,
but then objects with this striping will be ignored in the function which actually
store LOV EA.

I can not argue this is the best approach and wouldn't mind options.

[Alex Zhuravlev]

I think the last comment should have this explained. if anyone would like to keep this open or still have questions, please feel free to re-open.