lseek gets bad offset from nfs client with ganesha/gluster which supports SEEK

[Kinglong Mee <kinglongmee@xxxxxxxxx>]

The latest ganesha/gluster supports seek according to,

https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41#section-15.11

   From the given sa_offset, find the next data_content4 of type sa_what
   in the file.  If the server can not find a corresponding sa_what,
   then the status will still be NFS4_OK, but sr_eof would be TRUE.  If
   the server can find the sa_what, then the sr_offset is the start of
   that content.  If the sa_offset is beyond the end of the file, then
   SEEK MUST return NFS4ERR_NXIO.

For a file's filemap as,

Part    1: HOLE 0x0000000000000000 ---> 0x0000000000600000
Part    2: DATA 0x0000000000600000 ---> 0x0000000000700000
Part    3: HOLE 0x0000000000700000 ---> 0x0000000001000000

SEEK(0x700000, SEEK_DATA) gets result (sr_eof:1, sr_offset:0x70000) from ganesha/gluster;
SEEK(0x700000, SEEK_HOLE) gets result (sr_eof:0, sr_offset:0x70000) from ganesha/gluster.

If an application depends the lseek result for data searching, it may enter infinite loop.

        while (1) {
                next_pos = lseek(fd, cur_pos, seek_type);
                if (seek_type == SEEK_DATA) {
                        seek_type = SEEK_HOLE;
                } else {
                        seek_type = SEEK_DATA;
                }

                if (next_pos == -1) {
                        return ;

                cur_pos = next_pos;
        }

The lseek syscall always gets 0x70000 from nfs client for those two cases, 
but, if underlying filesystem is ext4/f2fs, or the nfs server is knfsd,
the lseek(0x700000, SEEK_DATA) gets ENXIO.

I wanna to know,
should I fix the ganesha/gluster as knfsd return ENXIO for the first case?
or should I fix the nfs client to return ENXIO for the first case?

thanks,
Kinglong Mee