Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-9342

It is possible that user defined LOVEA contains uninstantiated flag

Details

    • Bug
    • Resolution: Fixed
    • Critical
    • Lustre 2.10.0
    • Lustre 2.10.0
    • 3
    • 9223372036854775807

    Description

      This issue was created by maloo for bobijam <bobijam.xu@intel.com>

      This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/67af86be-2027-11e7-9073-5254006e85c2.

      The sub-test test_184d failed with the following error:

      swap /mnt/lustre/d184d.sanity/f184d.sanity-1 /mnt/lustre/d184d.sanity/f184d.sanity-2 layouts failed
      

      Info required for matching: sanity 184d

      If "lfs swap" tries to swap a file with partially instantiated layout, the partial LOVEA will passed into lod_declare_xattr_set()>lod_declare_striped_object()>lod_prepare_create()>lod_qos_parse_config()>lod_use_defined_striping(), so that lod_use_defined_striping() also need to take care of uninstantiated component entry.

      Attachments

        Issue Links

          Activity

            [LU-9342] It is possible that user defined LOVEA contains uninstantiated flag

            Jinshan Xiong (jinshan.xiong@intel.com) merged in patch https://review.whamcloud.com/26635/
            Subject: LU-9342 pfl: handle uninited component in user defined LOVEA
            Project: fs/lustre-release
            Branch: pfl
            Current Patch Set:
            Commit: 2c031f6651a5be4f8c5b58f986b584d7821b0f2b

            gerrit Gerrit Updater added a comment - Jinshan Xiong (jinshan.xiong@intel.com) merged in patch https://review.whamcloud.com/26635/ Subject: LU-9342 pfl: handle uninited component in user defined LOVEA Project: fs/lustre-release Branch: pfl Current Patch Set: Commit: 2c031f6651a5be4f8c5b58f986b584d7821b0f2b
            pjones Peter Jones made changes -
            Resolution New: Fixed [ 1 ]
            Status Original: Open [ 1 ] New: Resolved [ 5 ]
            pjones Peter Jones added a comment -

            Landed for 2.10

            pjones Peter Jones added a comment - Landed for 2.10

            Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/26619/
            Subject: LU-9342 pfl: handle uninited component in user defined LOVEA
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: cbd9992d513ec4d54fae97182747b2e31681a36e

            gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/26619/ Subject: LU-9342 pfl: handle uninited component in user defined LOVEA Project: fs/lustre-release Branch: master Current Patch Set: Commit: cbd9992d513ec4d54fae97182747b2e31681a36e
            eberglan Eric Bergland (Inactive) made changes -
            Link New: This issue is related to LU-9349 [ LU-9349 ]
            bobijam Zhenyu Xu added a comment -

            getxattr() get the EA buffer, and the magic of the LOVEA getting from the buffer surely doesn't contain LOV_MAGIC_DEF (which is a magic only set in the memory buffer, working with LCME_FL_INIT for MDS to inform LOD not to create OST objects), and when this LOVEA buffer passed to MDS with setxattr, MDS will treat it as a LOVEA template, and will create OST objects for the new file.

            Specifically, patch of this ticket fixes lod_use_defined_striping(), while the getxattr()+setxattr() call path comes to lod_qos_parse_config() will not call lod_use_defined_striping(), but go through it, creating lod_object::ldo_comp_entries according to the layout template without heeding the overly detailed information getting from the old file (including the LCME_FL_INIT flag and ost IDs).

             

            bobijam Zhenyu Xu added a comment - getxattr() get the EA buffer, and the magic of the LOVEA getting from the buffer surely doesn't contain LOV_MAGIC_DEF (which is a magic only set in the memory buffer, working with LCME_FL_INIT for MDS to inform LOD not to create OST objects), and when this LOVEA buffer passed to MDS with setxattr, MDS will treat it as a LOVEA template, and will create OST objects for the new file. Specifically, patch of this ticket fixes lod_use_defined_striping(), while the getxattr()+setxattr() call path comes to lod_qos_parse_config() will not call lod_use_defined_striping(), but go through it, creating lod_object::ldo_comp_entries according to the layout template without heeding the overly detailed information getting from the old file (including the LCME_FL_INIT flag and ost IDs).  
            bobijam Zhenyu Xu made changes -
            Link Original: This issue has to be finished together with LU-9362 [ LU-9362 ]
            bobijam Zhenyu Xu made changes -
            Link New: This issue has to be finished together with LU-9362 [ LU-9362 ]
            adilger Andreas Dilger made changes -
            Link New: This issue is related to LU-9346 [ LU-9346 ]

            It looks like LU-9346 is addressing the issue of LCME_FL_INIT being set in the layout?

            adilger Andreas Dilger added a comment - It looks like LU-9346 is addressing the issue of LCME_FL_INIT being set in the layout?

            People

              bobijam Zhenyu Xu
              maloo Maloo
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: