Page History

Introduction

If files are accidentally or maliciously deleted from a file system, the user data may be permanently lost. The Trash Can is a useful feature in file systems that acts as a temporary holding area, allowing users to store deleted files for a short time before they are permanently deleted. It provides a mechanism to restore or retrieve deleted files if needed, and automatically deletes the files once they become too old or the filesystem is too full.

...

• A file (or directory) is deleted from the Trash Can. In other words it have been deleted twice. The first deletion only moves the file to the Trash Can. The second deletion actually removes the file from the file system.

• The Trash Can is emptied of all of its contents.

Design and Implementation

The design for the Trash Can feature in Lustre is relatively straight forward.

...

Our mechanism only moves the regular files into the Trash Can upon its last unlink, but ignoring the directories.

It borrows lots of ideas from orphan and volatile files in Lustre (which stores in "ROOT/PENDING" directory on each MDT). During the format and setup, each MDT creates a "ROOT/TRASH" directory as a Trash Can to store "undeleted" files.

...

     0x200034021:0x1:0x0
     0x200034021:0x2:0x0
     ...
     # lfs trash ls /mnt/lustre/.lustre/recycle/MDT0002/0x200034021:0x1:0x0
     0 0 4096 Nov 14 08:11 [0x200034021:0x1:0x0]->/mnt/lustre/f1
     # lfs trash list /mnt/lustre/.lustre/recycle/MDT0002
     MDT index: 1
     uid gid   size delete time FID                    Fullpath
     0 0 4096  Nov 14 08:11     [0x200034021:0x1:0x0]->/mnt/lustre/f1
     0 0 32104 Nov 14 08:07     [0x200034021:0x2:0x0]->/mnt/lustre/dir/f2
     ...

Clean up files from the trash

It needs to automatically clean up files from the trash can when the filesystem becomes full. It cannot be that the user has to delete every file twice, and it cannot be that the filesystem is allowed to get 100% full (or even 90% full) due to files in the trash. There needs to be an automatic mechanism to clean up the trash to ensure that the filesystem performance does not degrade when users though they deleted files.

...

Also, there needs to be some accounting of files in the trash, so that "df" does not show the filesystem as 100% or 90% full all the time, but rather show only the non-trash space usage (= real usage - trash usage).

Per-user Trash Can

It can define a per-user TRASH/UID directory that is owned by that UID and mode 0600 to avoid world readable access. That avoids exposing files to other users that may be private, and also allows tracking space usage more clearly for each UID, so that a user's data can be purged more quickly if they are exceeding their quotas.

Trash support for a striped directory

It would better to implement a virtual ".Trash" subdirectory accessible in each directory in the filesystem that can be used to browse files/directories in the trash can and access them for recovery.

...

It should handle the case that a directory was restriped and the LMV layout was changed. In this case, the files under the directory will be migrated to another MDT. To simplify the impelmentation, we do not migrate the files according to the new LMV layout in the Trash Can. This may result in the lookup() operation will be issued to a wrong MDT and return -ENOENT wrongly (after files in the trash can are restored). However, the readdir() operations will still return all the dir entries in the striped trash even the parent LMV layout was re-striped and changed. Maybe it needs to migrate the files restored from the trash can according to their name hash once the LMV layout has been changed.

Orphans in Trash Can

For an orphan file, it means the file is still opened (but not closed) by a certain user. Upon its last unlink, it can directly move into the trash can and mark with LUSTRE_ORPHAN_FL | LUSTRE_TRASH_FL. And the orphans file can not be permanently deleted from the trash can until its last close().