Page History

...

The FID-based names of stub directories stored as .lustre/trash/MDTxxxx/UID/pFID directory are needed for efficient lookup of the parent FID during unlink.  However, these directory names are not very user-friendly when browsing the virtual .Trash directory in the filesystem namespace.  Rather than showing the pFID name to users during readdir() calls (ls, find, etc.) it would be better to look up the actual parent directory name via the FID→trusted.link xattr on the parent and return this to clients.  The FID number of the directory entry would be the FID of the stub directory itself, not the pFID that is used internally for identification.  While copying the trusted.link xattr over to the stub directory at creation would simplify this lookup, there is some risk that the name in the trusted.link xattr would become stale if the parent directory is renamed.  On the other hand, this may also be useful to preserve the original name of the directory in case some automated tool is renaming the original directory to a temporary name before deletion?

.Trash striped directory

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.

...