[LU-11687] allow "lfs fid2path" on open-unlinked files

• Status: Open
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Andreas Dilger
• Assignee: WC Triage
• Resolution: Unresolved

Description

Running "lfs fid2path" on an open-unlinked file returns an error:

# sleep 1000 < /mnt/testfs/hosts &
# lctl get_param mdt.*.exports.*.open_files
[0x200000401:0x4:0x0]
# lfs fid2path /mnt/testfs [0x200000401:0x4:0x0]
/mnt/testfs/hosts
# rm /mnt/testfs/hosts
# lfs fid2path /mnt/testfs [0x200000401:0x4:0x0]
lfs fid2path: cannot find '0x200000401:0x4:0x0': No such file or directory

This is not very useful if trying to find what file is consuming space.

It would be more useful to return something different for open-unlinked files. The kernel prints the pathname followed by "(deleted)" at the end. All open files are linked to the client exports and once the FID is mapped to the inode we could determine which NID has the file open. It would be possible to print e.g. "NID (deleted)" or similar and that it is possible to go to that client to find the file in question:

# lsof /mnt/testfs | grep "(deleted)"
sleep   22669 root    0r   REG 526,308960      158 144115205272502276 /mnt/testfs/hosts (deleted)

A more sophisticated approach would be to request the full pathname from the client, but that may not be practical.

Issue Links

• duplicates: LU-11638 lfs fid2path should list open-unlinke...
• is related to: LU-11678 sanity-quota test 1 fails with 'user ...
• is related to: LU-9629 lfs migrate does not work as a non-ro...

Comments

[Patrick Farrell (Inactive)]

Just a note for anyone else coming here about the test failures...

This ticket keeps getting tagged in test failures instead of LU-11678.  No test failures are actually linked to this particular ticket, they're all LU-11678.