[LU-10810] SEEK_HOLE and SEEK_DATA support for lseek

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.14.0
• Labels: medium
• Assignee: Mikhail Pershin
• Reporter: Lokesh N J (Inactive)

Description

lseek with SEEK_HOLE and SEEK_DATA are really helpful  and easy to use tools for any usersapce applications like copy and backup. Currently lustre has min support implementation as per the man page which is not that useful however lustre does support fiemap ioctl which can be used for mapping data in the file.
As we already have support for fiemap I guess with some implementation lustre can support SEEK_HOLE and SEEK_DATA flags. I guess having this support will be helpful to deal with sparse files. Any feedback about the implementation will be really helpful.

Issue Links

• duplicates: LU-13397 lfs migrate/mirror extend/resync does not preserve sparse file
• is related to: LU-14143 SEEK_HOLE returns -ENXIO if file ends at components boundary
• is related to: LU-11621 Add copy_file_range() API and use it for lfs migrate and mirror resync
• is related to: LU-14217 better SEEK_HOLE/DATA support in OSD-ZFS
• is related to: LU-1941 ZFS FIEMAP support
• is related to: LU-3606 Implement fallocate() support for ldiskfs Lustre
• is related to: LU-13155 "lfs migrate" and "lfs mirror" should fallocate() the target file

Comments

[Gerrit Updater]

Oleg Drokin ([e-mail]) uploaded a new patch: https://review.whamcloud.com/40570
Subject: LU-10810 tests: Fix calls to lseek_test_425
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 14cc826f465679531e352fd3852b115d369f6773

[Gerrit Updater]

Mike Pershin ([e-mail]) uploaded a new patch: https://review.whamcloud.com/40502
Subject: LU-10810 test: check seek support in tools
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9dc5e733c58bcdd12a987a4b06eb2f4845597dfb

[John Hammond]

coreutils cp added SEEK_HOLE/DATA support earlier this year. See https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=a6eaee501f6ec0c152abe88640203a64c390993e

[Gerrit Updater]

Mike Pershin ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39894
Subject: LU-10810 test: extended debug for lseek test
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f397a37df3b2f8f636686edc37b1720f58aa088a

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/39706/
Subject: LU-10810 osd: implement lseek method in OSD
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 947af94817f8eeb5e6108b0b3cde65419b13c8d3

[Andreas Dilger]

Please link to the GitHubissue and  pull request for exporting{{dmu_offset_next()}} when you have it. It would also be possible to use symbol lookup in the kernel until the kernel exports it. 

[Mikhail Pershin]

Things work with these three patches for normal files. ZFS is not working because needed function dmu_offset_next is not exported.

More work is needed for released files support, considering that tools uses SEEK_DATA/SEEK_HOLE prior data copying I suppose we need to restore released file during lseek operation.

Also more tests are needed for cases with concurrent access to the file while lseek is being performed.

[Gerrit Updater]

Mike Pershin ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39708
Subject: LU-10810 clio: SEEK_HOLE/SEEK_DATA on client side
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: c02e19f65667971f8320b20d99cd5db7199b7c8d

[Gerrit Updater]

Mike Pershin ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39707
Subject: LU-10810 ptlrpc: introduce OST_SEEK RPC
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 643bbb697e5439bb720acdb5038067b7bec6b83a

[Gerrit Updater]

Mike Pershin ([e-mail]) uploaded a new patch: https://review.whamcloud.com/39706
Subject: LU-10810 osd: implement lseek method in OSD
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 24983c305b0c64f42e57ae7d91cac81424099c0f

[Mikhail Pershin]

I choose to use separate OST_SEEK RPC instead of OST_GETATTR because that would make OST_GETATTR sort of ioctl which does one or another things depending on flags, moreover it is not returning ATTR even just separate information. Also this RPC itself looks obsoleted - it is being used now only to get data_version and would require also new MDT handler and new attr flag. Contrary, OST_SEEK is simple and handled by unified TGT handler for both MDT/OFD.