Details
-
Technical task
-
Resolution: Unresolved
-
Medium
-
None
-
None
-
None
-
3
-
9223372036854775807
Description
When files and directories are moved into the Trash Can, the UID/GID/PROJID will be changed from the existing IDs to the IDs defined by trash_can_uid, trash_can_gid, and trash_can_projid. The original UID/GID/PROJID should be saved in the trusted.unrmxattr for use during restore. That allows determining the amount of space used by the Trash Can using e.g. "lfs quota -p trash_can_projid" instead of having to scan the .lustre/trash directory usage, and allows users to free up space in their quota allocation when they delete files.
The space and inodes used by the trash_can_projid should be added to the free blocks and inodes returned by the statfs() call on the client, so that deleting files and directories appears to increase the amount of free space and inodes, even though those files are being preserved in the Trash Can.
By default "lfs df" should show the MDT/OST block and inode usage with the trash_can_projid usage added to the free/available blocks and inodes, A new option should be added "lfs df --trash" that shows the free/available blocks and inodes without the trash_can_projid compensation, so that it is possible to see the actual filesystem usage for diagnostic reasons.
If the trash_can_uid, trash_can_gid, or trash_can_projid parameters are set to -1by the administrator, then the respective UID, GID, and/or PROJID on the deleted inode should not be changed from the original values, and it is up to users to manage their own Trash Can usage. This may be needed if some users are abusing the Trash Can mechanism to circumvent quota usage, or if some users are creating and deleting large volumes of data that prevent other users from keeping any files in the Trash Can. In this case, the trash_can_projid will be invalid and should not be used to compensate for the free block or inode in the statfs() output.