Issues in the SRM v2.2 clarified during the WLCG Workshop on Jan. 22-26, 2007

In what follows we list the issues and agreements for the SRM v2.2 specifications that are published here.

  1. The meaning of the fields of TRequestSummary data structure has been clarified as follows:
    • numOfCompletedFiles = Successfully done + Failed + Aborted
    • numOfWaitingFiles = Queued
    • numOfFailedFiles = Failed + Aborted
    • numOfTotalFiles = Successfully done + Failed + Aborted + Queued + InProgress
  2. The overwrite mode is considered more powerful over pin. It is allowed to mark an valid TURL invalid when the owner of the surl issues an overwrite command, just like it is OK to call srmRm() and cause the valid TURLs be erased.
  3. In the case the newTimeExtended parameter exceeds the remaining lifetime of the space srmExtendFileLifeTime returns SRM_SUCCESS at request and file levels and TSURLLifetimeReturnStatus contains the remaining lifetime.
  4. srmExtendFileLifeTime is intended to negotiate a request of extension of the file lifetime or of the pin lifetime. Therefore, the method should return SRM_SUCCESS if the user request a lifetime which is less or more than what the system returns. The new lifetime is returned to the user.
  5. Implementations might refuse to return the listing of the TOP directory. In this case, the return code SRM_NOT_SUPPORTED should be returned at file level. Done: Test implemented in usecase/LsTopDir.s2.
  6. lifetimeLeft and lifetimeAssigned in TMetaDataPathDetail and in TMetaDataSpace have the following meaning:
    • lifetimeLeft = from current time till expiration
    • lifetimeAssigned = it can be ignored. It has no meaning.
    • lifetimeLeft = 0 means expired
    • lifetimeLeft = -1 means infinite.
  7. If newLifetime is unspecified in srmUpdateSpace or in srmExtendFileLifeTime[InSpace] the original lifetime must be left unchanged. Same for the space in srmUpdateSpace.
  8. The lifetime should be assumed to be the default if left unspecified in srmReserveSpace
  9. No negative values are allowed for remainingTotalRequestTime and remainingDeferredStartTime in srmBringOnline.
  10. If fullDetailedList is true for a single file, srmLs must return the following information: path, size, userPermission, lastModificationTime, file type, and lifetimeLeft. Checksum information (type and value) is highly desirable and should be returned if available. The same is true when a single directory is specified with NumOfLevel=0. If fullDetailedList is true and NumOfLevel=1 on a directory, all information above must be returned beside lifetimeLeft.
  11. The arguments count and offset in srmLs are supported only for the listing of a single directory. The returned SURLs must be ordered. The order can be implementation specific.
  12. NumOfLevel = 1 is the default in srmLs.
  13. NumOfLevel can assume values that are <= 1 in srmLs.
  14. Recursive srmLs is not supported at the moment.
  15. Recursive Rmdir is not supported at the moment. Implementations should return SRM_NOT_SUPPORTED.
  16. After a put cycle, in the space there is a copy of the file even if the handle (TURL) is expired/gone. The pin lifetime of the copy is the same as the SURL lifetime since this is the primary copy.
  17. Once a request is completed, nothing changes the status of the request. Therefore, an srmAbortFiles should not change the request level status code for the requests.
  18. srmAbort[Request|Files] after an srmPrepareToGet will abort uncompleted file and will set the pin lifetime to 0 for successfully completed files. srmAbort[Request|Files] after an srmPrepareToPut and before an srmPutDone will make the file disappear (what about files with overwrite=1 ? Should the system roll back ?). srmAbort[Request|Files] after a successfull srmPutDone will do nothing and it will return SRM_SUCCESS for those files. An explicit srmRm is necessary to remove the successfully completed files.
  19. The default value for the parameter overwriteOption in an srmPrepareToPut request is NEVER
  20. In srmExtendFileLifeTime a request that specifies both file and pin lifetime is invalid.
  21. The behaviour of srmAbortFiles on a copy request should be clarified. In COPY cases, either source or target has to be local to the SRM server. There can be one source SURL and multiple target SURLs in a request, regardless of PULL or PUSH. An srmAbortFiles will abort by the destination SURL, which means that all file transfer of the same destination SURL will be aborted if not already completed. Some implementation can abort based on both source and destination SURL.
  22. If a particular combination of Retention Policy and Access Latency is not supported in srmReserveSpace the server should return SRM_NOT_SUPPORTED or SRM_NO_FREE_SPACE
  23. A general behaviour of all srm method is that if a particular server does not support a particular optional parameter, SRM_NOT_SUPPORTED must be returned.
  24. If a second Abort[Request|Files] is issue, the returned code of the second invocation is SRM_SUCCESS and a NOP is performed.
  25. On an srmPrepareToPut if the fileStorageType requested is VOLATILE, the system cannot promote it to PERMANENT. This is to avoid charging the user with space accounting and with cleaning tasks. Therefore, the SRM server can either return SRM_NOT_SUPPORTED if the requested type is not supported or go ahead and satisfy the request.
  26. srmStatusOfPutRequest and srmStatusOfGetRequest return a status at request level that refers to the original request passed as input argument. If an array of SURL is also specified in input, the file level statuses returned by those methods refer only to those SURLs specified.
  27. Moving a SURL into itself results in a NOP. Moving a SURL in another one that exists already produces an SRM_DUPLICATION_ERROR.
  28. After an srmPrepareToPut operation where a TURL is returned, it is possible to execute a Mv operation on the corresponding SURL. This will not generate an error during the Mv operation. An srmPutDone on the original SURL will succeed with an SRM_SUCCESS return code at the file level.
  29. If an srmPrepareToPut is issue on a set of SURLs and the correspondent srmPutDone is executed on a subset of the original SURLs, the request level status code for the srmPutDone should refer to the subset of the SURLs requested.

-- FlaviaDonno - 2 Feb 2007

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2007-02-21 - FlaviaDonno
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    SRMDev All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback