DRAFT: ignore FS_IOC_FIEMAP failure with ENOTSUPP #647
Conversation
ofaaland
changed the title
|
I don't think ENOTSUPP is defined in the user space headers. It's in https://elixir.bootlin.com/linux/v4.18/source/include/linux/errno.h |
|
The patch now builds and silently ignores the error. With the same sparse file and layout as described in #644, the updated code's output is: |
Lustre 2.15.6 can return ENOTSUPP (524) in response to an FS_IOC_FIEMAP ioctl() call, for a file striped a certain way. This is a bug, it should return EOPNOTSUPP (95). The file can still be copied, fiemap just can't tell us where the holes are. A brief survey using google searches suggests ENOTSUPP (524) was historically intended for use internal to the kernel or drivers, but has occasionally been returned to users by different software, in ways that have meaning similar to ENOTSUP. Ignore the error as with ENOTSUP (95) so the file is copied without the use of fiemap. Notify the user that the copied file is not sparse. Fixes hpc#644 Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
|
Updated the patch to emit an INFO level message if fiemap ioctl() is not supported. Built and tested on mutt. I have not yet written the patch to use SEEK_HOLE et al. I chose INFO because WARN seemed too severe, given that the file we mention may not be sparse in the first place. This will be very chatty on Lustre 2.15. |
| if (errno == ENOTSUP) { | ||
| /* silently ignore */ | ||
| if (errno == ENOTSUP || errno == MFU_ERR_ENOTSUPP) { | ||
| MFU_LOG(MFU_LOG_INFO, "Destination file not sparse; FIEMAP not supported for src '%s'", |
There was a problem hiding this comment.
Do we know that the file isn't sparse here? I think a sparse lustre file would return ENOTSUP or MFU_ERR_ENOTSUPP here. Also, this should be talking about the source file, not the destination file.
There was a problem hiding this comment.
We do not know whether the source file is sparse or not. Since ioctl() failed, there's no way for us to know (until I write the patch to use SEEK_HOLE).
Also, this should be talking about the source file, not the destination file.
This is tricky. The source is where the ioctl() failed. But the destination is what we're writing, and it will not be sparse (unless, as I discovered, ZFS/Lustre figure it out and sparsify the file own their own).
There was a problem hiding this comment.
ok, I miss read the message
Lustre can return ENOTSUPP (524) in response to an FS_IOC_FIEMAP ioctl() call, for a file striped a certain way.
The file can still be copied, fiemap just can't tell us where the holes are.
A brief survey using google searches suggests ENOTSUPP (524) was historically intended for use internal to the kernel or drivers, but has occasionally been returned to users by different software, in ways that have meaning similar to ENOTSUP.
Ignore the error as with ENOTSUP (95) so the file is copied without the use of fiemap.
Fixes #644