-
Notifications
You must be signed in to change notification settings - Fork 0
Asynch fc operations rfc
RFC #10
Authors: S.Poss, A.Tsaregorodtsev
Last modified: 8.03.2013
File removal operations can take quite some time, especially bulk removal of multiple files at once. It is desirable to have asynchronous operation for file deletion as well as for other operations, e.g. replication. This would reduce the time needed to run those operations on the client side.
The proposal si to introduce a new file status in the DIRAC File Catalog - Trash. When a file is requested to be removed, its status is changed to Trash. This status will be by default invisible to the catalog client tools. Users will perceive this file as deleted. Since changing file status is a fast operation, users will experience an "immediate" file removal.
The actual file removal will be performed after a predefined grace period, e.g. 7 days. During this period the file can be recovered if the removal operation was requested by mistake. Users can still have access to the "Trash Bin" to see the files waiting for deletion. The storage consumption counters will still report the full total size of all the files including those in the Trash. Users will be provided with a client interface to empty the Trash unconditionally even before the grace period end.
The mechansim for the asynchronous file removal is based on the Request Management System (RMS). The removal requests can be sent to the RMS either at the same time as the file removal is requested with the time stamp to execute the request not before the end pf the grace period. Alternatively, a dedicated agent can be provided to send removal requests after the end of the grace period based on the last modification time stamp of the file in DFC.