Description
Implement "Trash Can" / Undelete functionality for Lustre.
This would have the MDS put newly-unlinked files into a .lustre/trash folder rather than deleting the OST objects immediately. The files could still be identified by the filenames in their trusted.link xattr, and could be linked by their FID name. Using the trusted.link xattr would also identify the parent directory FID from where the last link of the file was removed. Having some kind of hierarchy (e.g. directory named like UID/GID/PROJID) would avoid the trash directory itself from getting too large).
The MDS (or some external utility) would need to track the space usage on the OSTs and permanently delete files on OSTs that are getting "too full". Keeping track of LRU usage
It would be useful to keep track of the space usage on each of the OSTs and subtract the Trash usage from the actual space used when reporting df/statfs() on the clients.
The files being kept in Trash might be complicated for quota usage, because the OSTs will still have the space accounted for the end user. One option would be to assign the UID/GID/PROJID to a "trash" user so that this quota is not accounted against the end user, and keep the "original" UID/GID/PROJID in a separate xattr. Possibly only changing the UID/GID/PROJID of the OST objects to reduce the quota usage, and keeping them on the MDT would avoid this? That might potentially allow usrs to "avoid" quota by deleting their files temporarily. However, that is also risky for them if the files are automatically garbage collected.
Attachments
Issue Links
- is duplicated by
-
LU-18456 Recycle Bin for Lustre
- Open