From: walter harms <wharms@bfs.de>
To: "Hayes, Bill" <bill.hayes@hpe.com>
Cc: "ocfs2-devel@oss.oracle.com" <ocfs2-devel@oss.oracle.com>,
"mtk.manpages@gmail.com" <mtk.manpages@gmail.com>,
"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>
Subject: Re: Should lseek manpage reference OCFS2 versus OCFS?
Date: Wed, 23 Oct 2019 09:17:34 +0200 [thread overview]
Message-ID: <5DAFFE8E.6030401@bfs.de> (raw)
In-Reply-To: <CS1PR8401MB1031A3AE826CBEE15E95F60D8B680@CS1PR8401MB1031.NAMPRD84.PROD.OUTLOOK.COM>
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>
prev parent reply other threads:[~2019-10-23 7:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 22:30 Should lseek manpage reference OCFS2 versus OCFS? Hayes, Bill
2019-10-23 7:17 ` walter harms [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5DAFFE8E.6030401@bfs.de \
--to=wharms@bfs.de \
--cc=bill.hayes@hpe.com \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).