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

sanityn test_80b: test failed to respond and timed out

Details

    • Bug
    • Resolution: Cannot Reproduce
    • Minor
    • None
    • None
    • None
    • 3
    • 9223372036854775807

    Description

      This issue was created by maloo for nasf <fan.yong@intel.com>

      Please provide additional information about the failure here.

      This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/f72d26ba-ac24-11e6-971d-5254006e85c2.

      == sanityn test 80b: Accessing directory during migration ============================================ 10:50:49 (1479293449)
      start migration thread 4442
      accessing the migrating directory for 5 minutes...
      ...0 seconds
      ...10 seconds
      

      Attachments

        Issue Links

          Activity

            [LU-8845] sanityn test_80b: test failed to respond and timed out

            I noticed in the client console log from sanityn test_80b is being flooded with messages:
            https://testing.hpdd.intel.com/test_sets/c377fbac-b96a-11e7-8afb-52540065bddc
            https://testing.hpdd.intel.com/test_logs/c408c29a-b96a-11e7-8afb-52540065bddc/show_text

            lov_object.c:176:lov_init_sub()) header@ffff88006afe6348[0x0, 2, [0x340000400:0x362:0x0] hash] {
            lov_object.c:176:lov_init_sub()) ....lovsub@ffff88006afe63a8[0]
            lov_object.c:176:lov_init_sub()) ....osc@ffff880048726618id: 0x340000400:866 idx: 1 gen: 0 kms_valid: 1 kms 0 rc: 0 force_sync: 0 min_xid: 0 size: 0 mtime: 1508897801 atime: 1508897801 ctime: 1508897801 blocks: 0
            lov_object.c:176:lov_init_sub()) } header@ffff88006afe6348
            lov_object.c:176:lov_init_sub()) stripe 0 is already owned.
            lov_object.c:177:lov_init_sub()) header@ffff88004e694f20[0x0, 1, [0x2800013a3:0x138c:0x0] hash] {
            lov_object.c:177:lov_init_sub()) ....vvp@ffff88004e694f80(0 0) inode: ffff88004b663b10 180144069433889676/41943059 100644 1 1 ffff88004e694f80 [0x2800013a3:0x138c:0x0]
            lov_object.c:177:lov_init_sub()) ....lov@ffff88006b3d1140entries: 1, valid, lsm{ffff88006ad2fc80 0x0BD10BD0 1 0}:
            lov_object.c:177:lov_init_sub()) [ 0x0 , 0xffffffffffffffff ): { 0x0BD10BD0, 0, 0, 0x10, 1, 1048576 }
            lov_object.c:177:lov_init_sub()) header@ffff88006afe6348[0x0, 2, [0x340000400:0x362:0x0] hash] {
            lov_object.c:177:lov_init_sub()) ....lovsub@ffff88006afe63a8[0]
            lov_object.c:177:lov_init_sub()) ....osc@ffff880048726618id: 0x340000400:866 idx: 1 gen: 0 kms_valid: 1 kms 0 rc: 0 force_sync: 0 min_xid: 0 size: 0 mtime: 1508897801 atime: 1508897801 ctime: 1508897801 blocks: 0
            lov_object.c:177:lov_init_sub()) } header@ffff88006afe6348
            lov_object.c:177:lov_init_sub()) } header@ffff88004e694f20
            lov_object.c:177:lov_init_sub()) owned.
            lov_object.c:178:lov_init_sub()) header@ffff88004e694a50[0x0, 1, [0x2c00013a0:0x15:0x0]]
            lov_object.c:178:lov_init_sub()) try to own.
            lcommon_cl.c:180:cl_file_inode_init()) Failure to initialize cl object [0x2c00013a0:0x15:0x0]: -5
            llite_lib.c:2326:ll_prep_inode()) new_inode -fatal: rc -5
            

            If this is something that can happen during normal operation, then it probably shouldn't be dumped to the console.

            adilger Andreas Dilger added a comment - I noticed in the client console log from sanityn test_80b is being flooded with messages: https://testing.hpdd.intel.com/test_sets/c377fbac-b96a-11e7-8afb-52540065bddc https://testing.hpdd.intel.com/test_logs/c408c29a-b96a-11e7-8afb-52540065bddc/show_text lov_object.c:176:lov_init_sub()) header@ffff88006afe6348[0x0, 2, [0x340000400:0x362:0x0] hash] { lov_object.c:176:lov_init_sub()) ....lovsub@ffff88006afe63a8[0] lov_object.c:176:lov_init_sub()) ....osc@ffff880048726618id: 0x340000400:866 idx: 1 gen: 0 kms_valid: 1 kms 0 rc: 0 force_sync: 0 min_xid: 0 size: 0 mtime: 1508897801 atime: 1508897801 ctime: 1508897801 blocks: 0 lov_object.c:176:lov_init_sub()) } header@ffff88006afe6348 lov_object.c:176:lov_init_sub()) stripe 0 is already owned. lov_object.c:177:lov_init_sub()) header@ffff88004e694f20[0x0, 1, [0x2800013a3:0x138c:0x0] hash] { lov_object.c:177:lov_init_sub()) ....vvp@ffff88004e694f80(0 0) inode: ffff88004b663b10 180144069433889676/41943059 100644 1 1 ffff88004e694f80 [0x2800013a3:0x138c:0x0] lov_object.c:177:lov_init_sub()) ....lov@ffff88006b3d1140entries: 1, valid, lsm{ffff88006ad2fc80 0x0BD10BD0 1 0}: lov_object.c:177:lov_init_sub()) [ 0x0 , 0xffffffffffffffff ): { 0x0BD10BD0, 0, 0, 0x10, 1, 1048576 } lov_object.c:177:lov_init_sub()) header@ffff88006afe6348[0x0, 2, [0x340000400:0x362:0x0] hash] { lov_object.c:177:lov_init_sub()) ....lovsub@ffff88006afe63a8[0] lov_object.c:177:lov_init_sub()) ....osc@ffff880048726618id: 0x340000400:866 idx: 1 gen: 0 kms_valid: 1 kms 0 rc: 0 force_sync: 0 min_xid: 0 size: 0 mtime: 1508897801 atime: 1508897801 ctime: 1508897801 blocks: 0 lov_object.c:177:lov_init_sub()) } header@ffff88006afe6348 lov_object.c:177:lov_init_sub()) } header@ffff88004e694f20 lov_object.c:177:lov_init_sub()) owned. lov_object.c:178:lov_init_sub()) header@ffff88004e694a50[0x0, 1, [0x2c00013a0:0x15:0x0]] lov_object.c:178:lov_init_sub()) try to own. lcommon_cl.c:180:cl_file_inode_init()) Failure to initialize cl object [0x2c00013a0:0x15:0x0]: -5 llite_lib.c:2326:ll_prep_inode()) new_inode -fatal: rc -5 If this is something that can happen during normal operation, then it probably shouldn't be dumped to the console.
            yujian Jian Yu added a comment - One more failure instance on master branch: https://testing.hpdd.intel.com/test_sets/11eed540-ac8c-11e6-95d8-5254006e85c2

            People

              wc-triage WC Triage
              maloo Maloo
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: