Details
Minor 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.
Attachments
Issue Links
Activity
| Labels | Original: easy lug24dd support | New: easy lug24dd support trash_can |
| Link | New: This issue is related to LU-18914 [ LU-18914 ] |
| Link | New: This issue is related to EX-12100 [ EX-12100 ] |
| Link | New: This issue is related to EX-428 [ EX-428 ] |
| Description |
Original:
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 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 ? 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. |
New:
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 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. |
| Description |
Original:
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 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 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. |
New:
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 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 ? 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. |
| Labels | Original: easy lug24dd | New: easy lug24dd support |
| Description |
Original:
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.
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. |
New:
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 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 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. |
| Summary | Original: store JobID of process deleting file into user.job xattr | New: store JobID of process deleting file into xattr |