Details

    • Technical task
    • Resolution: Fixed
    • Minor
    • None
    • Lustre 2.4.0
    • None
    • 4253

    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.

      Attachments

        Activity

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

          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.

          bzzz Alex Zhuravlev added a comment - 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.

          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.

          bzzz Alex Zhuravlev added a comment - 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.

          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.

          adilger Andreas Dilger added a comment - 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.

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

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

          People

            bzzz Alex Zhuravlev
            adilger Andreas Dilger
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: