While investigating generic/285 failure on NFS on an XFS export I think
I
found a seek hole bug.
For a file with a hole/data pattern of hole, data, hole, data; it
appears
that SEEK_HOLE for pattern chunks larger than 65536 will be incorrect
for
seeking the start of the next hole after the first hole.
Here's my little test program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#define SEEK_HOLE 4
//#define CHUNK 65536
#define CHUNK 69632
int main(int argc, char **argv)
{
int fd;
off_t pos;
char *buf = NULL;
buf = malloc(4096);
memset(buf, 'a', 4096);
fd = open(argv[1], O_RDWR|O_CREAT|O_TRUNC, 0644);
for (pos = CHUNK; pos < CHUNK*2; pos += 4096)
pwrite(fd, buf, 4096, pos);
for (pos = CHUNK*3; pos < CHUNK*4; pos += 4096)
pwrite(fd, buf, 4096, pos);
pos = lseek(fd, CHUNK, SEEK_HOLE);
printf("SEEK_HOLE found second hole at %llu, expecting %llu\n",
pos, CHUNK*2);
close(fd);
}
[root@fedora ~]# ./test /exports/scratch/foo
SEEK_HOLE found second hole at 196608, expecting 139264
This is on 4.8, I did a bit of digging through XFS to see if I could
find
the problem, and it looks like XFS is interesting enough that I could
spend
all my time reading it... but I couldn't make serious progress and I
have to
go back to my actual job.
Let me know how I can help, or if I am just doing something exceedingly
stupid..
Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
