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.

...

There are two solution to handle striped directory for Trash Can:

• Solution 1:

Create a stub dir on trash Can upon the first file deletion of the striped directory. And the stub dir is using the master FID of the striped directory as the name and using the LMV layout of the striped directory as the layout configuration template.

When deleting a file or directory under the striped directory, the MDT first locates the stripe index of the stripe shard under which the file is deleting and then locates the corresponding stub shard of the stub directory and move the deleting file into the stub shard object.

Under this design, the user can directly access the files or directoies on Trash Can via ".Trash" or ".lustre/trash/MDTXXXX/[uid]/pFID". But the first deleting under a striped directory may cause a distributed metadata transcation. And Each deleting under the striped directory needs to locate the stub shard object any maybe need to obtain LMV layout of stub master striped dir remotely.

• Solution 2:

Do not create the stub striped dir on Trash Can upon the first file deletion of the striped directory. The MDT just creates a stub shard dir naming with the corresponding shard FID of the parent directory and move the file into this stub shard dir in Trash Can.

When access trash files via ".Trash", the client will construct a virtual file with the FID same with the parent dir, but the version of FID is set with (FID_VERSION_TRASH = 1).

And the shard FIDs are constructed with the corresponding FIDs with same FID names in Trash Can.

Under this design, the user can only access the trash files for striped directories via ".Trash", can not access them via ".lustre/MDTXXXX/pFID" as the master stub directory does not exist yet until the deleting the parent directory.

When deleting the parent directory, the MDT will create a stripe stub directory on Trash Can where the shards' FIDs are FIDs of corresponding stub shard objects.

Under this design, the file deleting is simpler. Just need to create a stub shard object with the name same as the FID of the corresponding shard for the parent striped directory. But the access via ".Trash" and deleting the striped directory is complex.

For a striped directory, its ".Trash" directory is also a vitual striped directory with each stripe on the same location (MDTs) where the shard FID is the FID of the corresponding stub directory on that MDT. If the stub directory on a certain MDT does not exist (or not create yet), the client lookup() or readdir() under ".Trash" directory should skip the stripe. The master FID of the virtual ".Trash" directory could be same with the FID of the parent directory but with f_ver setting with 1 (FID_VERSION_TRASH = 1) to distinguish them.

...