[man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN

[man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Document the STATX_DIOALIGN support for statx()
(https://git.kernel.org/linus/725737e7c21d2d25).

Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---

I'm resending this now that support for STATX_DIOALIGN has been merged
upstream.

v3: updated mentions of Linux version, fixed some punctuation, and added
    a Reviewed-by

v2: rebased onto man-pages master branch, mentioned xfs, and updated
    link to patchset

 man2/open.2  | 43 ++++++++++++++++++++++++++++++++-----------
 man2/statx.2 | 29 +++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/man2/open.2 b/man2/open.2
index deba7e4ea..b8617e0d2 100644
--- a/man2/open.2
+++ b/man2/open.2
@@ -1732,21 +1732,42 @@ of user-space buffers and the file offset of I/Os.
 In Linux alignment
 restrictions vary by filesystem and kernel version and might be
 absent entirely.
-However there is currently no filesystem\-independent
-interface for an application to discover these restrictions for a given
-file or filesystem.
-Some filesystems provide their own interfaces
-for doing so, for example the
+The handling of misaligned
+.B O_DIRECT
+I/Os also varies; they can either fail with
+.B EINVAL
+or fall back to buffered I/O.
+.PP
+Since Linux 6.1,
+.B O_DIRECT
+support and alignment restrictions for a file can be queried using
+.BR statx (2),
+using the
+.B STATX_DIOALIGN
+flag.
+Support for
+.B STATX_DIOALIGN
+varies by filesystem; see
+.BR statx (2).
+.PP
+Some filesystems provide their own interfaces for querying
+.B O_DIRECT
+alignment restrictions, for example the
 .B XFS_IOC_DIOINFO
 operation in
 .BR xfsctl (3).
+.B STATX_DIOALIGN
+should be used instead when it is available.
 .PP
-Under Linux 2.4, transfer sizes, the alignment of the user buffer,
-and the file offset must all be multiples of the logical block size
-of the filesystem.
-Since Linux 2.6.0, alignment to the logical block size of the
-underlying storage (typically 512 bytes) suffices.
-The logical block size can be determined using the
+If none of the above is available, then direct I/O support and alignment
+restrictions can only be assumed from known characteristics of the filesystem,
+the individual file, the underlying storage device(s), and the kernel version.
+In Linux 2.4, most block device based filesystems require that the file offset
+and the length and memory address of all I/O segments be multiples of the
+filesystem block size (typically 4096 bytes).
+In Linux 2.6.0, this was relaxed to the logical block size of the block device
+(typically 512 bytes).
+A block device's logical block size can be determined using the
 .BR ioctl (2)
 .B BLKSSZGET
 operation or from the shell using the command:
diff --git a/man2/statx.2 b/man2/statx.2
index 0d1b4591f..50397057d 100644
--- a/man2/statx.2
+++ b/man2/statx.2
@@ -61,7 +61,12 @@ struct statx {
        containing the filesystem where the file resides */
     __u32 stx_dev_major;   /* Major ID */
     __u32 stx_dev_minor;   /* Minor ID */
+
     __u64 stx_mnt_id;      /* Mount ID */
+
+    /* Direct I/O alignment restrictions */
+    __u32 stx_dio_mem_align;
+    __u32 stx_dio_offset_align;
 };
 .EE
 .in
@@ -247,6 +252,8 @@ STATX_BTIME	Want stx_btime
 STATX_ALL	The same as STATX_BASIC_STATS | STATX_BTIME.
 	It is deprecated and should not be used.
 STATX_MNT_ID	Want stx_mnt_id (since Linux 5.8)
+STATX_DIOALIGN	Want stx_dio_mem_align and stx_dio_offset_align
+	(since Linux 6.1; support varies by filesystem)
 .TE
 .in
 .PP
@@ -407,6 +414,28 @@ This is the same number reported by
 .BR name_to_handle_at (2)
 and corresponds to the number in the first field in one of the records in
 .IR /proc/self/mountinfo .
+.TP
+.I stx_dio_mem_align
+The alignment (in bytes) required for user memory buffers for direct I/O
+.BR "" ( O_DIRECT )
+on this file, or 0 if direct I/O is not supported on this file.
+.IP
+.B STATX_DIOALIGN
+.IR "" ( stx_dio_mem_align
+and
+.IR stx_dio_offset_align )
+is supported on block devices since Linux 6.1.
+The support on regular files varies by filesystem; it is supported by ext4,
+f2fs, and xfs since Linux 6.1.
+.TP
+.I stx_dio_offset_align
+The alignment (in bytes) required for file offsets and I/O segment lengths for
+direct I/O
+.BR "" ( O_DIRECT )
+on this file, or 0 if direct I/O is not supported on this file.
+This will only be nonzero if
+.I stx_dio_mem_align
+is nonzero, and vice versa.
 .PP
 For further information on the above fields, see
 .BR inode (7).

base-commit: bc28d289e5066fc626df260bafc249846a0f6ae6
-- 
2.37.3

Re: [man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN

[Darrick J. Wong]

On Tue, Oct 04, 2022 at 10:43:07AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Document the STATX_DIOALIGN support for statx()
> (https://git.kernel.org/linus/725737e7c21d2d25).
> 
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> 
> I'm resending this now that support for STATX_DIOALIGN has been merged
> upstream.

Woo!  Thank you for getting this over the line! :)

--D

> v3: updated mentions of Linux version, fixed some punctuation, and added
>     a Reviewed-by
> 
> v2: rebased onto man-pages master branch, mentioned xfs, and updated
>     link to patchset
> 
>  man2/open.2  | 43 ++++++++++++++++++++++++++++++++-----------
>  man2/statx.2 | 29 +++++++++++++++++++++++++++++
>  2 files changed, 61 insertions(+), 11 deletions(-)
> 
> diff --git a/man2/open.2 b/man2/open.2
> index deba7e4ea..b8617e0d2 100644
> --- a/man2/open.2
> +++ b/man2/open.2
> @@ -1732,21 +1732,42 @@ of user-space buffers and the file offset of I/Os.
>  In Linux alignment
>  restrictions vary by filesystem and kernel version and might be
>  absent entirely.
> -However there is currently no filesystem\-independent
> -interface for an application to discover these restrictions for a given
> -file or filesystem.
> -Some filesystems provide their own interfaces
> -for doing so, for example the
> +The handling of misaligned
> +.B O_DIRECT
> +I/Os also varies; they can either fail with
> +.B EINVAL
> +or fall back to buffered I/O.
> +.PP
> +Since Linux 6.1,
> +.B O_DIRECT
> +support and alignment restrictions for a file can be queried using
> +.BR statx (2),
> +using the
> +.B STATX_DIOALIGN
> +flag.
> +Support for
> +.B STATX_DIOALIGN
> +varies by filesystem; see
> +.BR statx (2).
> +.PP
> +Some filesystems provide their own interfaces for querying
> +.B O_DIRECT
> +alignment restrictions, for example the
>  .B XFS_IOC_DIOINFO
>  operation in
>  .BR xfsctl (3).
> +.B STATX_DIOALIGN
> +should be used instead when it is available.
>  .PP
> -Under Linux 2.4, transfer sizes, the alignment of the user buffer,
> -and the file offset must all be multiples of the logical block size
> -of the filesystem.
> -Since Linux 2.6.0, alignment to the logical block size of the
> -underlying storage (typically 512 bytes) suffices.
> -The logical block size can be determined using the
> +If none of the above is available, then direct I/O support and alignment
> +restrictions can only be assumed from known characteristics of the filesystem,
> +the individual file, the underlying storage device(s), and the kernel version.
> +In Linux 2.4, most block device based filesystems require that the file offset
> +and the length and memory address of all I/O segments be multiples of the
> +filesystem block size (typically 4096 bytes).
> +In Linux 2.6.0, this was relaxed to the logical block size of the block device
> +(typically 512 bytes).
> +A block device's logical block size can be determined using the
>  .BR ioctl (2)
>  .B BLKSSZGET
>  operation or from the shell using the command:
> diff --git a/man2/statx.2 b/man2/statx.2
> index 0d1b4591f..50397057d 100644
> --- a/man2/statx.2
> +++ b/man2/statx.2
> @@ -61,7 +61,12 @@ struct statx {
>         containing the filesystem where the file resides */
>      __u32 stx_dev_major;   /* Major ID */
>      __u32 stx_dev_minor;   /* Minor ID */
> +
>      __u64 stx_mnt_id;      /* Mount ID */
> +
> +    /* Direct I/O alignment restrictions */
> +    __u32 stx_dio_mem_align;
> +    __u32 stx_dio_offset_align;
>  };
>  .EE
>  .in
> @@ -247,6 +252,8 @@ STATX_BTIME	Want stx_btime
>  STATX_ALL	The same as STATX_BASIC_STATS | STATX_BTIME.
>  	It is deprecated and should not be used.
>  STATX_MNT_ID	Want stx_mnt_id (since Linux 5.8)
> +STATX_DIOALIGN	Want stx_dio_mem_align and stx_dio_offset_align
> +	(since Linux 6.1; support varies by filesystem)
>  .TE
>  .in
>  .PP
> @@ -407,6 +414,28 @@ This is the same number reported by
>  .BR name_to_handle_at (2)
>  and corresponds to the number in the first field in one of the records in
>  .IR /proc/self/mountinfo .
> +.TP
> +.I stx_dio_mem_align
> +The alignment (in bytes) required for user memory buffers for direct I/O
> +.BR "" ( O_DIRECT )
> +on this file, or 0 if direct I/O is not supported on this file.
> +.IP
> +.B STATX_DIOALIGN
> +.IR "" ( stx_dio_mem_align
> +and
> +.IR stx_dio_offset_align )
> +is supported on block devices since Linux 6.1.
> +The support on regular files varies by filesystem; it is supported by ext4,
> +f2fs, and xfs since Linux 6.1.
> +.TP
> +.I stx_dio_offset_align
> +The alignment (in bytes) required for file offsets and I/O segment lengths for
> +direct I/O
> +.BR "" ( O_DIRECT )
> +on this file, or 0 if direct I/O is not supported on this file.
> +This will only be nonzero if
> +.I stx_dio_mem_align
> +is nonzero, and vice versa.
>  .PP
>  For further information on the above fields, see
>  .BR inode (7).
> 
> base-commit: bc28d289e5066fc626df260bafc249846a0f6ae6
> -- 
> 2.37.3
> 

Re: [man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 5850 bytes --]

Hi Eric,

On 10/4/22 19:43, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Document the STATX_DIOALIGN support for statx()
> (https://git.kernel.org/linus/725737e7c21d2d25).
> 
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> Signed-off-by: Eric Biggers <ebiggers@google.com>

Please see some formatting comments below.

> ---
> 
> I'm resending this now that support for STATX_DIOALIGN has been merged
> upstream.

Thanks.

Cheers,
Alex

> 
> v3: updated mentions of Linux version, fixed some punctuation, and added
>      a Reviewed-by
> 
> v2: rebased onto man-pages master branch, mentioned xfs, and updated
>      link to patchset
> 
>   man2/open.2  | 43 ++++++++++++++++++++++++++++++++-----------
>   man2/statx.2 | 29 +++++++++++++++++++++++++++++
>   2 files changed, 61 insertions(+), 11 deletions(-)
> 
> diff --git a/man2/open.2 b/man2/open.2
> index deba7e4ea..b8617e0d2 100644
> --- a/man2/open.2
> +++ b/man2/open.2
> @@ -1732,21 +1732,42 @@ of user-space buffers and the file offset of I/Os.
>   In Linux alignment
>   restrictions vary by filesystem and kernel version and might be
>   absent entirely.
> -However there is currently no filesystem\-independent
> -interface for an application to discover these restrictions for a given
> -file or filesystem.
> -Some filesystems provide their own interfaces
> -for doing so, for example the
> +The handling of misaligned
> +.B O_DIRECT
> +I/Os also varies; they can either fail with
> +.B EINVAL
> +or fall back to buffered I/O.
> +.PP
> +Since Linux 6.1,
> +.B O_DIRECT
> +support and alignment restrictions for a file can be queried using
> +.BR statx (2),
> +using the
> +.B STATX_DIOALIGN
> +flag.
> +Support for
> +.B STATX_DIOALIGN
> +varies by filesystem; see
> +.BR statx (2).
> +.PP
> +Some filesystems provide their own interfaces for querying
> +.B O_DIRECT
> +alignment restrictions, for example the
>   .B XFS_IOC_DIOINFO
>   operation in
>   .BR xfsctl (3).
> +.B STATX_DIOALIGN
> +should be used instead when it is available.
>   .PP
> -Under Linux 2.4, transfer sizes, the alignment of the user buffer,
> -and the file offset must all be multiples of the logical block size
> -of the filesystem.
> -Since Linux 2.6.0, alignment to the logical block size of the
> -underlying storage (typically 512 bytes) suffices.
> -The logical block size can be determined using the
> +If none of the above is available, then direct I/O support and alignment

Please use semantic newlines.

See man-pages(7):
    Use semantic newlines
        In the source of a manual page, new sentences  should  be
        started on new lines, long sentences should be split into
        lines  at  clause breaks (commas, semicolons, colons, and
        so on), and long clauses should be split at phrase bound‐
        aries.  This convention,  sometimes  known  as  "semantic
        newlines",  makes it easier to see the effect of patches,
        which often operate at the level of individual sentences,
        clauses, or phrases.


> +restrictions can only be assumed from known characteristics of the filesystem,
> +the individual file, the underlying storage device(s), and the kernel version.
> +In Linux 2.4, most block device based filesystems require that the file offset
> +and the length and memory address of all I/O segments be multiples of the
> +filesystem block size (typically 4096 bytes).
> +In Linux 2.6.0, this was relaxed to the logical block size of the block device
> +(typically 512 bytes).
> +A block device's logical block size can be determined using the
>   .BR ioctl (2)
>   .B BLKSSZGET
>   operation or from the shell using the command:
> diff --git a/man2/statx.2 b/man2/statx.2
> index 0d1b4591f..50397057d 100644
> --- a/man2/statx.2
> +++ b/man2/statx.2
> @@ -61,7 +61,12 @@ struct statx {
>          containing the filesystem where the file resides */
>       __u32 stx_dev_major;   /* Major ID */
>       __u32 stx_dev_minor;   /* Minor ID */
> +
>       __u64 stx_mnt_id;      /* Mount ID */
> +
> +    /* Direct I/O alignment restrictions */
> +    __u32 stx_dio_mem_align;
> +    __u32 stx_dio_offset_align;
>   };
>   .EE
>   .in
> @@ -247,6 +252,8 @@ STATX_BTIME	Want stx_btime
>   STATX_ALL	The same as STATX_BASIC_STATS | STATX_BTIME.
>   	It is deprecated and should not be used.
>   STATX_MNT_ID	Want stx_mnt_id (since Linux 5.8)
> +STATX_DIOALIGN	Want stx_dio_mem_align and stx_dio_offset_align
> +	(since Linux 6.1; support varies by filesystem)
>   .TE
>   .in
>   .PP
> @@ -407,6 +414,28 @@ This is the same number reported by
>   .BR name_to_handle_at (2)
>   and corresponds to the number in the first field in one of the records in
>   .IR /proc/self/mountinfo .
> +.TP
> +.I stx_dio_mem_align
> +The alignment (in bytes) required for user memory buffers for direct I/O
> +.BR "" ( O_DIRECT )

.RB and remove the "".

> +on this file, or 0 if direct I/O is not supported on this file.
> +.IP
> +.B STATX_DIOALIGN
> +.IR "" ( stx_dio_mem_align

.RI

> +and
> +.IR stx_dio_offset_align )
> +is supported on block devices since Linux 6.1.
> +The support on regular files varies by filesystem; it is supported by ext4,
> +f2fs, and xfs since Linux 6.1.
> +.TP
> +.I stx_dio_offset_align
> +The alignment (in bytes) required for file offsets and I/O segment lengths for
> +direct I/O
> +.BR "" ( O_DIRECT )
> +on this file, or 0 if direct I/O is not supported on this file.
> +This will only be nonzero if
> +.I stx_dio_mem_align
> +is nonzero, and vice versa.
>   .PP
>   For further information on the above fields, see
>   .BR inode (7).
> 
> base-commit: bc28d289e5066fc626df260bafc249846a0f6ae6

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN

[Darrick J. Wong]

On Sat, Oct 08, 2022 at 03:56:22AM +0200, Alejandro Colomar wrote:
> Hi Eric,
> 
> On 10/4/22 19:43, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Document the STATX_DIOALIGN support for statx()
> > (https://git.kernel.org/linus/725737e7c21d2d25).
> > 
> > Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> 
> Please see some formatting comments below.
> 
> > ---
> > 
> > I'm resending this now that support for STATX_DIOALIGN has been merged
> > upstream.
> 
> Thanks.
> 
> Cheers,
> Alex
> 
> > 
> > v3: updated mentions of Linux version, fixed some punctuation, and added
> >      a Reviewed-by
> > 
> > v2: rebased onto man-pages master branch, mentioned xfs, and updated
> >      link to patchset
> > 
> >   man2/open.2  | 43 ++++++++++++++++++++++++++++++++-----------
> >   man2/statx.2 | 29 +++++++++++++++++++++++++++++
> >   2 files changed, 61 insertions(+), 11 deletions(-)
> > 
> > diff --git a/man2/open.2 b/man2/open.2
> > index deba7e4ea..b8617e0d2 100644
> > --- a/man2/open.2
> > +++ b/man2/open.2
> > @@ -1732,21 +1732,42 @@ of user-space buffers and the file offset of I/Os.
> >   In Linux alignment
> >   restrictions vary by filesystem and kernel version and might be
> >   absent entirely.
> > -However there is currently no filesystem\-independent
> > -interface for an application to discover these restrictions for a given
> > -file or filesystem.
> > -Some filesystems provide their own interfaces
> > -for doing so, for example the
> > +The handling of misaligned
> > +.B O_DIRECT
> > +I/Os also varies; they can either fail with
> > +.B EINVAL
> > +or fall back to buffered I/O.
> > +.PP
> > +Since Linux 6.1,
> > +.B O_DIRECT
> > +support and alignment restrictions for a file can be queried using
> > +.BR statx (2),
> > +using the
> > +.B STATX_DIOALIGN
> > +flag.
> > +Support for
> > +.B STATX_DIOALIGN
> > +varies by filesystem; see
> > +.BR statx (2).
> > +.PP
> > +Some filesystems provide their own interfaces for querying
> > +.B O_DIRECT
> > +alignment restrictions, for example the
> >   .B XFS_IOC_DIOINFO
> >   operation in
> >   .BR xfsctl (3).
> > +.B STATX_DIOALIGN
> > +should be used instead when it is available.
> >   .PP
> > -Under Linux 2.4, transfer sizes, the alignment of the user buffer,
> > -and the file offset must all be multiples of the logical block size
> > -of the filesystem.
> > -Since Linux 2.6.0, alignment to the logical block size of the
> > -underlying storage (typically 512 bytes) suffices.
> > -The logical block size can be determined using the

I'm not so familiar with semantic newlines-- is there an automated
reflow program that fixes these problems mechanically, or is this
expected to be performed manually by manpage authors?

If manually, do the items in a comma-separated list count as clauses?

Would the next two paragraphs of this email reformat into semantic
newlines like so?

	In the source of a manual page,
	new sentences should  be started on new lines,
	long sentences should be split into lines at clause breaks
	(commas, semicolons, colons, and so on),
	and long clauses should be split at phrase boundaries.
	This convention,
	sometimes known as "semantic newlines",
	makes it easier to see the effect of patches,
	which often operate at the level of individual sentences, clauses, or phrases.

Do we still line-wrap at 72^W74^W78^W80 columns?

and would the proposed manpage text read:

	If none of the above is available,
	then direct I/O support and alignment restrictions can only be assumed
	from known characteristics of the filesystem,
	the individual file,
	the underlying storage device(s),
	and the kernel version.
	In Linux 2.4,
	most block device based filesystems require that the file offset and the
	length and memory address of all I/O segments be multiples of the
	filesystem block size
	(typically 4096 bytes).
	In Linux 2.6.0,
	this was relaxed to the logical block size of the block device
	(typically 512 bytes).
	A block device's logical block size can be determined using the
	.BR ioctl (2)
	.B BLKSSZGET
	operation or from the shell using the command:

--D

> > +If none of the above is available, then direct I/O support and alignment
> 
> Please use semantic newlines.
> 
> See man-pages(7):
>    Use semantic newlines
>        In the source of a manual page, new sentences  should  be
>        started on new lines, long sentences should be split into
>        lines  at  clause breaks (commas, semicolons, colons, and
>        so on), and long clauses should be split at phrase bound‐
>        aries.  This convention,  sometimes  known  as  "semantic
>        newlines",  makes it easier to see the effect of patches,
>        which often operate at the level of individual sentences,
>        clauses, or phrases.
> 
> 
> > +restrictions can only be assumed from known characteristics of the filesystem,
> > +the individual file, the underlying storage device(s), and the kernel version.
> > +In Linux 2.4, most block device based filesystems require that the file offset
> > +and the length and memory address of all I/O segments be multiples of the
> > +filesystem block size (typically 4096 bytes).
> > +In Linux 2.6.0, this was relaxed to the logical block size of the block device
> > +(typically 512 bytes).
> > +A block device's logical block size can be determined using the
> >   .BR ioctl (2)
> >   .B BLKSSZGET
> >   operation or from the shell using the command:
> > diff --git a/man2/statx.2 b/man2/statx.2
> > index 0d1b4591f..50397057d 100644
> > --- a/man2/statx.2
> > +++ b/man2/statx.2
> > @@ -61,7 +61,12 @@ struct statx {
> >          containing the filesystem where the file resides */
> >       __u32 stx_dev_major;   /* Major ID */
> >       __u32 stx_dev_minor;   /* Minor ID */
> > +
> >       __u64 stx_mnt_id;      /* Mount ID */
> > +
> > +    /* Direct I/O alignment restrictions */
> > +    __u32 stx_dio_mem_align;
> > +    __u32 stx_dio_offset_align;
> >   };
> >   .EE
> >   .in
> > @@ -247,6 +252,8 @@ STATX_BTIME	Want stx_btime
> >   STATX_ALL	The same as STATX_BASIC_STATS | STATX_BTIME.
> >   	It is deprecated and should not be used.
> >   STATX_MNT_ID	Want stx_mnt_id (since Linux 5.8)
> > +STATX_DIOALIGN	Want stx_dio_mem_align and stx_dio_offset_align
> > +	(since Linux 6.1; support varies by filesystem)
> >   .TE
> >   .in
> >   .PP
> > @@ -407,6 +414,28 @@ This is the same number reported by
> >   .BR name_to_handle_at (2)
> >   and corresponds to the number in the first field in one of the records in
> >   .IR /proc/self/mountinfo .
> > +.TP
> > +.I stx_dio_mem_align
> > +The alignment (in bytes) required for user memory buffers for direct I/O
> > +.BR "" ( O_DIRECT )
> 
> .RB and remove the "".
> 
> > +on this file, or 0 if direct I/O is not supported on this file.
> > +.IP
> > +.B STATX_DIOALIGN
> > +.IR "" ( stx_dio_mem_align
> 
> .RI
> 
> > +and
> > +.IR stx_dio_offset_align )
> > +is supported on block devices since Linux 6.1.
> > +The support on regular files varies by filesystem; it is supported by ext4,
> > +f2fs, and xfs since Linux 6.1.
> > +.TP
> > +.I stx_dio_offset_align
> > +The alignment (in bytes) required for file offsets and I/O segment lengths for
> > +direct I/O
> > +.BR "" ( O_DIRECT )
> > +on this file, or 0 if direct I/O is not supported on this file.
> > +This will only be nonzero if
> > +.I stx_dio_mem_align
> > +is nonzero, and vice versa.
> >   .PP
> >   For further information on the above fields, see
> >   .BR inode (7).
> > 
> > base-commit: bc28d289e5066fc626df260bafc249846a0f6ae6
> 
> -- 
> <http://www.alejandro-colomar.es/>

Semantic newlines (was: [man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 7066 bytes --]

Hi Darrick,

On 10/10/22 17:22, Darrick J. Wong wrote:
> 
> I'm not so familiar with semantic newlines-- is there an automated

The following commit contains interesting details about them and their 
origins:

<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit?id=6ff6f43d68164f99a8c3fb66f4525d145571310c>

> reflow program that fixes these problems mechanically, or is this
> expected to be performed manually by manpage authors?

I don't know of a reflow program that fixes this.
The biggest issue is that
parsing natural language is not exactly easy.

So, it is expected to be performed manually by authors.

> 
> If manually, do the items in a comma-separated list count as clauses?

It depends.
Pedantically, yes;
but we evaluate it case by case,
depending on the length of each sentence
and the existence of subordinate clauses.
So author taste is important there and respected.

> 
> Would the next two paragraphs of this email reformat into semantic
> newlines like so?
> 
> 	In the source of a manual page,
> 	new sentences should  be started on new lines,
> 	long sentences should be split into lines at clause breaks
> 	(commas, semicolons, colons, and so on),
> 	and long clauses should be split at phrase boundaries.
> 	This convention,
> 	sometimes known as "semantic newlines",
> 	makes it easier to see the effect of patches,
> 	which often operate at the level of individual sentences, clauses, or phrases.
> 
 >
 > --D
 >
 >>> +If none of the above is available, then direct I/O support and 
alignment
 >>
 >> Please use semantic newlines.
 >>
 >> See man-pages(7):
 >>     Use semantic newlines
 >>         In the source of a manual page, new sentences  should  be
 >>         started on new lines, long sentences should be split into
 >>         lines  at  clause breaks (commas, semicolons, colons, and
 >>         so on), and long clauses should be split at phrase bound‐
 >>         aries.  This convention,  sometimes  known  as  "semantic
 >>         newlines",  makes it easier to see the effect of patches,
 >>         which often operate at the level of individual sentences,
 >>         clauses, or phrases.
 >>
 >>
 >>> +restrictions can only be assumed from known characteristics of the 
filesystem,
 >>> +the individual file, the underlying storage device(s), and the 
kernel version.
 >>> +In Linux 2.4, most block device based filesystems require that the 
file offset
 >>> +and the length and memory address of all I/O segments be multiples 
of the
 >>> +filesystem block size (typically 4096 bytes).
 >>> +In Linux 2.6.0, this was relaxed to the logical block size of the 
block device
 >>> +(typically 512 bytes).
 >>> +A block device's logical block size can be determined using the
 >>>    .BR ioctl (2)
 >>>    .B BLKSSZGET
 >>>    operation or from the shell using the command:
 >>> diff --git a/man2/statx.2 b/man2/statx.2
 >>> index 0d1b4591f..50397057d 100644
 >>> --- a/man2/statx.2
 >>> +++ b/man2/statx.2
 >>> @@ -61,7 +61,12 @@ struct statx {
 >>>           containing the filesystem where the file resides */
 >>>        __u32 stx_dev_major;   /* Major ID */
 >>>        __u32 stx_dev_minor;   /* Minor ID */
 >>> +
 >>>        __u64 stx_mnt_id;      /* Mount ID */
 >>> +
 >>> +    /* Direct I/O alignment restrictions */
 >>> +    __u32 stx_dio_mem_align;
 >>> +    __u32 stx_dio_offset_align;
 >>>    };
 >>>    .EE
 >>>    .in
 >>> @@ -247,6 +252,8 @@ STATX_BTIME	Want stx_btime
 >>>    STATX_ALL	The same as STATX_BASIC_STATS | STATX_BTIME.
 >>>    	It is deprecated and should not be used.
 >>>    STATX_MNT_ID	Want stx_mnt_id (since Linux 5.8)
 >>> +STATX_DIOALIGN	Want stx_dio_mem_align and stx_dio_offset_align
 >>> +	(since Linux 6.1; support varies by filesystem)
 >>>    .TE
 >>>    .in
 >>>    .PP
 >>> @@ -407,6 +414,28 @@ This is the same number reported by
 >>>    .BR name_to_handle_at (2)
 >>>    and corresponds to the number in the first field in one of the 
records in
 >>>    .IR /proc/self/mountinfo .
 >>> +.TP
 >>> +.I stx_dio_mem_align
 >>> +The alignment (in bytes) required for user memory buffers for 
direct I/O
 >>> +.BR "" ( O_DIRECT )
 >>
 >> .RB and remove the "".
 >>
 >>> +on this file, or 0 if direct I/O is not supported on this file.
 >>> +.IP
 >>> +.B STATX_DIOALIGN
 >>> +.IR "" ( stx_dio_mem_align
 >>
 >> .RI
 >>
 >>> +and
 >>> +.IR stx_dio_offset_align )
 >>> +is supported on block devices since Linux 6.1.
 >>> +The support on regular files varies by filesystem; it is supported 
by ext4,
 >>> +f2fs, and xfs since Linux 6.1.
 >>> +.TP
 >>> +.I stx_dio_offset_align
 >>> +The alignment (in bytes) required for file offsets and I/O segment 
lengths for
 >>> +direct I/O
 >>> +.BR "" ( O_DIRECT )
 >>> +on this file, or 0 if direct I/O is not supported on this file.
 >>> +This will only be nonzero if
 >>> +.I stx_dio_mem_align
 >>> +is nonzero, and vice versa.
 >>>    .PP
 >>>    For further information on the above fields, see
 >>>    .BR inode (7).
 >>>
 >>> base-commit: bc28d289e5066fc626df260bafc249846a0f6ae6
 >>
 >> --
 >> <http://www.alejandro-colomar.es/>
 >
 >
 >
Yes, that would be correct;
in fact,
you almost matched the actual source code of the manual page.
There are two differences:
one comma at which we don't break (but we could),
and also we break the last line before the list.

See the source code here:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/man-pages.7#n612>

> Do we still line-wrap at 72^W74^W78^W80 columns?

Yes, 80 is a strong limit.

Normally,
breaking at the level of clauses
will leave very few lines passing that limit.
When there's such a case,
you can break further at the level of phrases,
and I doubt any line will pass the 80-col boundary after that.

> 
> and would the proposed manpage text read:
> 
> 	If none of the above is available,
> 	then direct I/O support and alignment restrictions can only be assumed
> 	from known characteristics of the filesystem,
> 	the individual file,
> 	the underlying storage device(s),
> 	and the kernel version.
> 	In Linux 2.4,
> 	most block device based filesystems require that the file offset and the

block device based would need some '-' as it's a compound adjective (I 
don't know the exact rules in English when there are more than two words 
forming such an adjective, please check).

I would break after 'require that'.

> 	length and memory address of all I/O segments be multiples of the

And right before 'be', I think.

> 	filesystem block size
> 	(typically 4096 bytes).
> 	In Linux 2.6.0,
> 	this was relaxed to the logical block size of the block device
> 	(typically 512 bytes).
> 	A block device's logical block size can be determined using the
> 	.BR ioctl (2)
> 	.B BLKSSZGET
> 	operation or from the shell using the command:

But mostly looks good.

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [man-pages PATCH v3] statx.2, open.2: document STATX_DIOALIGN

[Eric Biggers]

Hi Alejandro,

On Sat, Oct 08, 2022 at 03:56:22AM +0200, Alejandro Colomar wrote:
> > +If none of the above is available, then direct I/O support and alignment
> 
> Please use semantic newlines.
> 
> See man-pages(7):
>    Use semantic newlines
>        In the source of a manual page, new sentences  should  be
>        started on new lines, long sentences should be split into
>        lines  at  clause breaks (commas, semicolons, colons, and
>        so on), and long clauses should be split at phrase bound‐
>        aries.  This convention,  sometimes  known  as  "semantic
>        newlines",  makes it easier to see the effect of patches,
>        which often operate at the level of individual sentences,
>        clauses, or phrases.

I tried to do this in v4.  It seems very arbitrary, though, so if you want
further changes to the newlines I recommend just making them when committing the
patch.

Note that a better way to review changes to text is to do a word diff instead of
a line diff.

- Eric