Details
Description
It would be useful to store the jobid in an xattr in the MDT inode at unlink time (if it fits) for forensic purposes, to track down which client/process has deleted files in the filesystem, like LU-13031 stores the JobID of the processes that created the file in user.job.
It isn't clear that this could be easily done for the OST objects, since they are all deleted by threads on the MDS. Passing on the JobID from the MDT inode to the OST inode might be possible to do, but likely adds unnecessary complexity for something that is of only very occasional value.
It isn't clear if it would be better to re-use the user.job xattr for this, or if a new user.del xattr should be used in case both of these values are useful at the same time (the actual xattr name could be configurable via mdt.*.job_xattr_del on the MDS, as it is for the creation JobID). The main question is whether there is space in the inode for these xattrs, and whether the removal xattr would actually be written to disk after an unlink? I think yes, since the block deallocation is definitely updating the inode.
This would be very useful in combination with the Trash Can feature, so that it is possible to identify which process/node is deleting files, if there is some kind of rogue process deleting files unexpectedly (which has definitely happened in the past).
We could potentially store the JobID in the trusted.unrm xattr to save on the xattr overhead from storing a separate user.del xattr. This would have the drawback that it is only visible to the root user.