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

nanosecond timestamp support for Lustre

Details

    • Improvement
    • Resolution: Unresolved
    • Major
    • None
    • Lustre 2.4.0
    • 3
    • 4515

    Description

      The current Lustre network protocol has support for a 64-bit timestamp of seconds, but does not have a field for passing the nanosecond timestamp from clients to servers and back again.

      It would be relatively straight-forward to put 3x __u32 nanosecond timestamps in the reserved fields in struct obdo and struct mdt_body. These fields are currently always initialized to 0, so there wouldn't even need to be a protocol change or feature to begin using these fields for nanoseconds - just copy them in/out of the RPC structures, and old clients/servers will just store 0 there, and ignore any nanosecond timestamps that are sent to them (no differently than they do today).

      It is more complex to add the nanosecond timestamps to struct ost_lvb, which is most commonly used for glimpse locks (stat) on OST objects. This will require a structure change to fit the extra 3x __u32 nanosecond timestamps into ost_lvb, which may require a protocol change. It may be possible if this structure is passed in a separate ptlrpc message buffer that the larger size will be ignored by older clients, which would avoid the need for additional complexity for interoperability.

      Attachments

        Issue Links

          Activity

            [LU-1158] nanosecond timestamp support for Lustre
            mrasobarnett Matt Rásó-Barnett made changes -
            Link New: This issue is related to EXR-574 [ EXR-574 ]
            adilger Andreas Dilger made changes -
            Labels New: always_except
            adilger Andreas Dilger made changes -
            Labels Original: always_except
            adilger Andreas Dilger made changes -
            Labels New: always_except
            adilger Andreas Dilger made changes -
            Link New: This issue is related to LU-18108 [ LU-18108 ]
            flei Feng Lei made changes -
            Link New: This issue is related to LU-17963 [ LU-17963 ]
            flei Feng Lei made changes -
            Link New: This issue is related to LU-18069 [ LU-18069 ]
            adilger Andreas Dilger made changes -
            Link New: This issue is related to LR-12 [ LR-12 ]
            adilger Andreas Dilger made changes -
            Description Original: The current Lustre network protocol has support for a 64-bit timestamp of seconds, but does not have a field for passing the nanosecond timestamp from clients to servers and back again.

            It would be relatively straight-forward to put 3x __u32 nanosecond timestamps in the reserved fields in struct obdo and struct mdt_body. These fields are currently always initialized to 0, so there wouldn't even need to be a protocol change or feature to begin using these fields for nanoseconds - just copy them in/out of the RPC structures, and old clients/servers will just store 0 there, and ignore any nanosecond timestamps that are sent to them (no differently than they do today).

            It is more complex to add the nanosecond timestamps to struct ost_lvb, which is most commonly used for glimpse locks (stat) on OST objects. This will require a structure change to fit the extra 3x __u32 nanosecond timestamps into ost_lvb, which may require a protocol change. It _may_ be possible if this structure is passed in a separate ptlrpc message buffer that the larger size will be ignored by older clients, which would avoid the need for additional complexity for interoperability.
            New: The current Lustre network protocol has support for a 64-bit timestamp of seconds, but does not have a field for passing the nanosecond timestamp from clients to servers and back again.

            It would be relatively straight-forward to put 3x {{\_\_u32}} nanosecond timestamps in the reserved fields in {{struct obdo}} and {{struct mdt\_body}}. These fields are currently always initialized to 0, so there wouldn't even need to be a protocol change or feature to begin using these fields for nanoseconds - just copy them in/out of the RPC structures, and old clients/servers will just store 0 there, and ignore any nanosecond timestamps that are sent to them (no differently than they do today).

            It is more complex to add the nanosecond timestamps to struct ost_lvb, which is most commonly used for glimpse locks (stat) on OST objects. This will require a structure change to fit the extra 3x {{\_\_u32}} nanosecond timestamps into ost_lvb, which may require a protocol change. It _may_ be possible if this structure is passed in a separate ptlrpc message buffer that the larger size will be ignored by older clients, which would avoid the need for additional complexity for interoperability.
            adilger Andreas Dilger made changes -
            Assignee Original: James A Simmons [ simmonsja ] New: Feng Lei [ flei ]

            People

              flei Feng Lei
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

                Created:
                Updated: