fiemap error

[kevin-harms]

Getting the following error when source is Lustre and I request spare support (-S)

[2023-01-30T21:48:23] [1] [/home/harms/working/daos/mpifileutils/src/common/mfu_flist_copy.c:1853] ERROR: fiemap ioctl() failed for src '/soft/daos/mpifileutils/share/man/man1/dsync.1' (errno=22 Invalid argument)

I'm thinking this is because the structure initialization for the ioctl is bad. Running the following Lustre version:

harms@uan-0002:~/working/daos/tools> lfs --version
lfs 2.15.0.6_rc2_cray_14_g2408acc

I don't know if Lustre is strict about maintaining format of ioctl calls between different releases.

[adilger]

This looks like it might be https://jira.whamcloud.com/browse/LU-16480 which fixes a bug in the FIEMAP handling. This needs a small client-side patch to fix.

That said, if this code is using FIEMAP for determining sparseness of a file, it might be better to use lseek(fd, SEEK_HOLE) since this also works for PFL files (otherwise Lustre will return EOPNOTSUPP for FIEMAP calls).

The SEEK_HOLE/SEEK_DATA functionality was added in 2.14, but is a client-only patch.

[ofaaland]

@defaziogiancarlo @daltonbohning

My patch above, #647 , improves things in the sense of removing the scary warning.

I'm thinking that might be a mistake, though, at least in the long term. The user explicitly asked for sparse files with -S or --sparse, and by silently ignoring this error and falling back on a naive copy we convert a sparse file to a not-sparse one. You can see that in my output posted to the PR, it claims my test dir has 95GiB of data, but really it has 118K of data (as reported by du).

In #545 Andreas suggests using lseek() with SEEK_HOLE and SEEK_DATA instead.

Instead of silently ignoring the error, I think we should replace the scary error message with a more user friendly one - "fiemap() is not supported for this file, falling back on a non-sparse copy" or something like that.

Then, for the longer term, first try fiemap(), then try the lseek() method, and only then fall back on the naive copy and emit the warning. I'm prepared to modify the code to use the lseek() method, I've for that working in my little test harness.

What do you think?

[defaziogiancarlo]

That all looks good to me. For the longer term fix, that's basically what we thought should happen when we discussed this issue during recent filesystem migration problems due to a very large sparse file. That is, the (fiemap, then lseek, then give up and do non-sparse) sequence.

Warning the user that their file is being copied non-sparse even when the sparse flag is set also seems like a good idea, as opposed to the current lack of message. Maybe there should be an option to not allow falling back to non-sparse? A user could accidentally exceed a quota and suddenly their jobs using the same file system would fail in the case that they try to sync some huge sparse file.

[ofaaland]

Maybe there should be an option to not allow falling back to non-sparse? A user could accidentally exceed a quota and suddenly their jobs using the same file system would fail in the case that they try to sync some huge sparse file.

I agree, the current code seems a bit like a booby-trap.

I'll look at some other tools and see how they handle this, and post here.