...

If the same filename is repeatedly created and deleted within the same parent directory, then the deleted files will have conflicts when moved into the pFID directory in the Trash Can.   This may happen for files that are edited by the user, and a temporary file like .FILENAME.tmp12345 is created and written by the editor, and then renamed over the original FILENAME (causing it to be deleted) so that the file contents are not lost if the new file is only partially written.  In such cases, the same FILENAME may be deleted many times.

To disambiguate the files in Trash, the conflicting filenames should be disambiguated by appending a timestamp to the filename, like filenameFILENAME.2025-04-03-00:11:24, possibly adding .microseconds if there is still a conflict.  It isn't totally clear whether it would be better to use the timestamp from when the file was deleted, or when the file was created.  Both have some value to help users distinguish between the different versions.

...

Files that only exist for a very short time (e.g. temporary files) should not necessarily be preserved in the Trash Can, or they can quickly overwhelm the available capacity of the filesystem, and result in important files being purged from trash and/or filling the trash faster than files can be cleaned up. Files marked with the I_LINKABLE flag on the MDS (from O_TMPFILE, or Lustre Volatile files, see LU-18844) should not be preserved in the Trash Can .  if they are not linked into a file in the namespace.  It would be useful to have a tunable parameter that sets a minimum age for files to be preserved in the Trash Can (e.g. 65 minutes?) so that files that are frequently created and deleted are not preserved since they could consume a considerable amount of space.

...

For filesystem-level/namespace backup and restore, the .Trash directory will not be visible to the backup utility during namespace traversal, so deleted files in the Trash will not be backed up.

For MDT-level/device backup and restore, the Trash directory and its contents will be backed up in the same way as any other directory in the filesystem.  The stub pFID directory is named by the parent directory FID, so it will be backed up and restored as-is (its FID is not really important, but should be treated normally).  The FID on the actual parent directory will be preserved in the trusted.lma xattr, but the FID lookup in the restored OI will not be possible until after the initial post-restore OI Scrub has completed.  Otherwise, the FID lookup in the restored OI will reference the old inode number, which will reference a wrong or unused inode number/generation, and should return -EINPROGRESS or possibly -ESTALE.

  However, if a deleted directory is restored from Trash then if it has a new FID (== new inode number) the backup utilities may consider this to be a new directory and back it up again.  At a minimum, it would be desirable to preserve the inode number.  Similarly, HSM integration may depend on the FID of the file, so it may be desirable to preserve the original parent FID of the directory when it is restored from Trash.  A deleted directory could only be restored to use the same FID if the original directory had been deleted.

For MDT-level/device backup and restore, the Trash directory and its contents will be backed up in the same way as any other directory in the filesystem.  The stub pFID directory is named by the parent directory FID, so it will be backed up and restored as-is (its FID is not really important, but should be treated normally).  The FID on the actual parent directory will be preserved in the trusted.lma xattr, but the FID lookup in the restored OI will not be possible until after the initial post-restore OI Scrub has completed.  Otherwise, the FID lookup in the restored OI will reference the old inode number, which will reference a wrong or unused inode number/generation, and should return -EINPROGRESS or possibly -ESTALE.

It may be necessary to add special support to OI Scrub/LFSCK to handle the Trash directory on each MDT, so that it can do a top-level scan of the stub pFID directories to confirm that the parent FID still references a valid parent directory.

Trash Can and fscrypt Files and Directories

When an fscrypt directory is deleted, the encryption context on the directory must be copied from the parent directory to the new pFID stub directory when it is first created, so that the encrypted filenames and contents can be accessed properly via the .Trash/ directory, as well as if an encrypted file or directory is undeleted.  The fscrypt context is partly derived from the parent directory, as well as a unique per-inode Cryptographic nonce value that ensures the encrypted data is unique, even if the same data is encrypted multiple timesIt may be necessary to add special support to OI Scrub/LFSCK to handle the Trash directory on each MDT, so that it can do a top-level scan of the stub pFID directories to confirm that the parent FID still references a valid parent directory.

Virtual .Trash Directory Support 

...