> On Nov 8, 2018, at 4:07 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> I think that at this stage we should make tmpfs behaviour match the
> other filesystems.
>
> If the manpage doesn't match the kernel's behaviour for this
> linux-specific feature(?) then we should fix the manpage.
>
> If we find that the behaviour should actually change (and there's a way
> of doing that in a reasonably back-compatible manner) then let's change
> all filesystems and the manpage.
>
> OK?
I did a little research, and according to lseek(2):
SEEK_DATA and SEEK_HOLE are nonstandard extensions also present in
Solaris, FreeBSD, and DragonFly BSD; they are proposed for inclusion
in the next POSIX revision (Issue 8).
I wrote a brief test program that operated on a file of 1024 zeroes and found
that on an ext4 file system, lseek(2) matches Solaris' behavior on ZFS:
Solaris/ZFS
===========
lseek(3, -1, SEEK_HOLE) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_HOLE) returned 1024
lseek(3, 1, SEEK_HOLE) returned 1024
lseek(3, -1, SEEK_DATA) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_DATA) returned 0
lseek(3, 1, SEEK_DATA) returned 1
Linux/ext4
==========
lseek(3, -1, SEEK_HOLE) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_HOLE) returned 1024
lseek(3, 1, SEEK_HOLE) returned 1024
lseek(3, -1, SEEK_DATA) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_DATA) returned 0
lseek(3, 1, SEEK_DATA) returned 1
That validates the xfstest expectations that a negative passed offset should
return ENXIO.
I suggest the man page wording be changed to read:
ENXIO whence is SEEK_DATA or SEEK_HOLE, and the file offset is negative or
beyond the end of the file.
unless you'd prefer an alternative statement.
Thanks!!
