Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.6.0, Lustre 2.5.2
    • Lustre 2.4.0
    • Single node test system running 2.4.0
    • 3
    • 11184

    Description

      Relates to LU-2298

      It seems that changelog is not logging file truncates. I've not tested 2.4.1 but when I do I'll update this.

      [root@coolermaster lustre]# dd if=/dev/zero of=truncate bs=1M count=10
      10+0 records in
      10+0 records out
      

      Results

      7269327 01CREAT 00:36:19.512971520 2013.10.22 0x0 t=[0x200000bde:0x103e8:0x0] p=[0x200000007:0x1:0x0] truncate
      7269328 11CLOSE 00:36:19.543968971 2013.10.22 0x242 t=[0x200000bde:0x103e8:0x0]
      

      Truncate (Reduce)

      truncate -s -1000 truncate
      

      Results

      7269329 14SATTR 00:36:39.677314618 2013.10.22 0xe t=[0x200000bde:0x103e8:0x0]
      7269330 11CLOSE 00:36:39.678314537 2013.10.22 0x42 t=[0x200000bde:0x103e8:0x0]
      

      Truncate

      {extend}
      truncate -s +1000 truncate
      

      Results

      7269331 14SATTR 00:36:54.378106399 2013.10.22 0xe t=[0x200000bde:0x103e8:0x0]
      7269332 11CLOSE 00:36:54.379106360 2013.10.22 0x42 t=[0x200000bde:0x103e8:0x0]
      

      Possibly the wrong flag 'SATTR' is being sent here, as when I reduce the mask down to just TRUNC flag nothing comes through at all.

      -cf

      Attachments

        Activity

          [LU-4131] Changelog TRUNC flag is missing
          pjones Peter Jones added a comment -

          Landed for 2.5.2 and 2.6

          pjones Peter Jones added a comment - Landed for 2.5.2 and 2.6
          rdeshmukh_xyratex Rahul Deshmukh (Inactive) added a comment - - edited

          Apologies here, actually forgot to mention the new patch link.
          I have abandoned first patch as Andreas suggested to created it
          for master branch.

          Here is the required patch.

          Patch: http://review.whamcloud.com/#/c/9723/

          I will also put one more cleanup (kind of optional/independent) patch in a day or two.

          rdeshmukh_xyratex Rahul Deshmukh (Inactive) added a comment - - edited Apologies here, actually forgot to mention the new patch link. I have abandoned first patch as Andreas suggested to created it for master branch. Here is the required patch. Patch: http://review.whamcloud.com/#/c/9723/ I will also put one more cleanup (kind of optional/independent) patch in a day or two.

          Hi Cliff,

          The first patch addressed another issue within CL_MTIME and was actually out of scope for this problem. I'll have to check to see where this issue stands on our side and will update this ticket appropriately.

          -cf

          cfaber#1 Colin Faber [X] (Inactive) added a comment - Hi Cliff, The first patch addressed another issue within CL_MTIME and was actually out of scope for this problem. I'll have to check to see where this issue stands on our side and will update this ticket appropriately. -cf

          The first patch is marked Abandoned, will you be submitting a new patch, or should we close this issue?

          cliffw Cliff White (Inactive) added a comment - The first patch is marked Abandoned, will you be submitting a new patch, or should we close this issue?
          rdeshmukh_xyratex Rahul Deshmukh (Inactive) added a comment - Patch : http://review.whamcloud.com/#/c/9639/

          note CL_TRUNC doesn't seem to be actually used anywhere.

          nrutman Nathan Rutman added a comment - note CL_TRUNC doesn't seem to be actually used anywhere.
          nrutman Nathan Rutman added a comment - - edited

          Some additional info:
          "Use of truncate(2) does not produce any change log entries, and therefore the action is invisible. Since it appears that all versions of truncate(1) actually do an open(2)/ftruncate(2)/close(2) sequence, the CLOSE event informs of the possible size change. This is only an issue when there is a program using truncate(2) and not following that action with an open for writing and eventual close."
          Truncate(2) is specifically referring to the C library function truncate.
          This is an issue for us currently. My reading of LU-2298 suggests that this is a problem because size information is not being communicated to the MDS. (Because size on MDS is not implemented.)
          Is this correct? As it stands, what would we need to do to get this logged on the MDS?

          nrutman Nathan Rutman added a comment - - edited Some additional info: "Use of truncate(2) does not produce any change log entries, and therefore the action is invisible. Since it appears that all versions of truncate(1) actually do an open(2)/ftruncate(2)/close(2) sequence, the CLOSE event informs of the possible size change. This is only an issue when there is a program using truncate(2) and not following that action with an open for writing and eventual close." Truncate(2) is specifically referring to the C library function truncate. This is an issue for us currently. My reading of LU-2298 suggests that this is a problem because size information is not being communicated to the MDS. (Because size on MDS is not implemented.) Is this correct? As it stands, what would we need to do to get this logged on the MDS?

          People

            utopiabound Nathaniel Clark
            cfaber#1 Colin Faber [X] (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: