Should lseek manpage reference OCFS2 versus OCFS?

Should lseek manpage reference OCFS2 versus OCFS?

[Hayes, Bill]

On the lseek man page (http://man7.org/linux/man-pages/man2/lseek.2.html), in its description of SEEK_DATA and SEEK_HOLE it says that: The SEEK_HOLE and SEEK_DATA operations are supported for the following filesystems:
       *  Btrfs (since Linux 3.1)
       *  OCFS (since Linux 3.2)
       *  XFS (since Linux 3.5)
       *  ext4 (since Linux 3.8)
       *  tmpfs(5) (since Linux 3.8)
       *  NFS (since Linux 3.18)
       *  FUSE (since Linux 4.5)

I think that the reference to OCFS on the manpage should actually be to the OCFS2 file system.  

I think the 'OCFS (since Linux 3.2)' manpage reference is referring to this commit to OCFS2:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs?id=93862d5e1ab875664c6cc95254fc365028a48bb1

This OCFS2 commit was included as part of the Linux 3.2-rc4 drop (https://lwn.net/Articles/470337/).

Can someone with more experience with OCFS and OCFS2 confirm that the manpage should be changed to OCFS2 instead of OCFS?

Bill

	commit 93862d5e1ab875664c6cc95254fc365028a48bb1
	Author: Sunil Mushran <sunil.mushran@oracle.com>
	Date:   Mon Jul 25 14:58:15 2011 -0700

		ocfs2: Implement llseek()


		SEEK_HOLE sets the file pointer to the start of either a hole or an unwritten
		(preallocated) extent, that is greater than or equal to the supplied offset.

		SEEK_DATA sets the file pointer to the start of an allocated extent (not
		unwritten) that is greater than or equal to the supplied offset.

		If the supplied offset is on a desired region, then the file pointer is set
		to it. Offsets greater than or equal to the file size return -ENXIO.

		Unwritten (preallocated) extents are considered holes because the file system
		treats reads to such regions in the same way as it does to holes.

		Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com>

Re: Should lseek manpage reference OCFS2 versus OCFS?

[walter harms]

Am 23.10.2019 00:30, schrieb Hayes, Bill:
> On the lseek man page (http://man7.org/linux/man-pages/man2/lseek.2.html), in its description of SEEK_DATA and SEEK_HOLE it says that: The SEEK_HOLE and SEEK_DATA operations are supported for the following filesystems:
>        *  Btrfs (since Linux 3.1)
>        *  OCFS (since Linux 3.2)
>        *  XFS (since Linux 3.5)
>        *  ext4 (since Linux 3.8)
>        *  tmpfs(5) (since Linux 3.8)
>        *  NFS (since Linux 3.18)
>        *  FUSE (since Linux 4.5)
> 
> I think that the reference to OCFS on the manpage should actually be to the OCFS2 file system.  
> 
> I think the 'OCFS (since Linux 3.2)' manpage reference is referring to this commit to OCFS2:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs?id=93862d5e1ab875664c6cc95254fc365028a48bb1
> 
> This OCFS2 commit was included as part of the Linux 3.2-rc4 drop (https://lwn.net/Articles/470337/).
> 
> Can someone with more experience with OCFS and OCFS2 confirm that the manpage should be changed to OCFS2 instead of OCFS?
> 
> Bill

Hi Bill,
i do not think this is the right way. The lssek man page
should say: the availability of SEEK_DATA and SEEK_HOLE
depend on the underlying filesystem.

On the other side the <filesystem> man pages need an entry
what they support. Having that list inside lseek(3) means
to have a big list of filesystems to maintain here.

re,
 wh



> 
> 	commit 93862d5e1ab875664c6cc95254fc365028a48bb1
> 	Author: Sunil Mushran <sunil.mushran@oracle.com>
> 	Date:   Mon Jul 25 14:58:15 2011 -0700
> 
> 		ocfs2: Implement llseek()
> 
> 
> 		SEEK_HOLE sets the file pointer to the start of either a hole or an unwritten
> 		(preallocated) extent, that is greater than or equal to the supplied offset.
> 
> 		SEEK_DATA sets the file pointer to the start of an allocated extent (not
> 		unwritten) that is greater than or equal to the supplied offset.
> 
> 		If the supplied offset is on a desired region, then the file pointer is set
> 		to it. Offsets greater than or equal to the file size return -ENXIO.
> 
> 		Unwritten (preallocated) extents are considered holes because the file system
> 		treats reads to such regions in the same way as it does to holes.
> 
> 		Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com>