All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>
Subject: [PATCH v3 12/29] docs: filesystems: convert fiemap.txt to ReST
Date: Mon, 27 Apr 2020 23:17:04 +0200	[thread overview]
Message-ID: <9182d49ffca7a0580e32ab24ecf5f8cc8d8924af.1588021877.git.mchehab+huawei@kernel.org> (raw)
In-Reply-To: <cover.1588021877.git.mchehab+huawei@kernel.org>

- Add a SPDX header;
- Some whitespace fixes and new line breaks;
- Mark literal blocks as such;
- Add it to filesystems/index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../filesystems/{fiemap.txt => fiemap.rst}    | 133 +++++++++---------
 Documentation/filesystems/index.rst           |   1 +
 2 files changed, 69 insertions(+), 65 deletions(-)
 rename Documentation/filesystems/{fiemap.txt => fiemap.rst} (70%)

diff --git a/Documentation/filesystems/fiemap.txt b/Documentation/filesystems/fiemap.rst
similarity index 70%
rename from Documentation/filesystems/fiemap.txt
rename to Documentation/filesystems/fiemap.rst
index ac87e6fda842..2a572e7edc08 100644
--- a/Documentation/filesystems/fiemap.txt
+++ b/Documentation/filesystems/fiemap.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
 ============
 Fiemap Ioctl
 ============
@@ -10,9 +12,9 @@ returns a list of extents.
 Request Basics
 --------------
 
-A fiemap request is encoded within struct fiemap:
+A fiemap request is encoded within struct fiemap::
 
-struct fiemap {
+  struct fiemap {
 	__u64	fm_start;	 /* logical offset (inclusive) at
 				  * which to start mapping (in) */
 	__u64	fm_length;	 /* logical length of mapping which
@@ -23,7 +25,7 @@ struct fiemap {
 	__u32	fm_extent_count; /* size of fm_extents array (in) */
 	__u32	fm_reserved;
 	struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */
-};
+  };
 
 
 fm_start, and fm_length specify the logical range within the file
@@ -51,12 +53,12 @@ nothing to prevent the file from changing between calls to FIEMAP.
 
 The following flags can be set in fm_flags:
 
-* FIEMAP_FLAG_SYNC
-If this flag is set, the kernel will sync the file before mapping extents.
+FIEMAP_FLAG_SYNC
+  If this flag is set, the kernel will sync the file before mapping extents.
 
-* FIEMAP_FLAG_XATTR
-If this flag is set, the extents returned will describe the inodes
-extended attribute lookup tree, instead of its data tree.
+FIEMAP_FLAG_XATTR
+  If this flag is set, the extents returned will describe the inodes
+  extended attribute lookup tree, instead of its data tree.
 
 
 Extent Mapping
@@ -75,18 +77,18 @@ complete the requested range and will not have the FIEMAP_EXTENT_LAST
 flag set (see the next section on extent flags).
 
 Each extent is described by a single fiemap_extent structure as
-returned in fm_extents.
+returned in fm_extents::
 
-struct fiemap_extent {
-	__u64	fe_logical;  /* logical offset in bytes for the start of
-			      * the extent */
-	__u64	fe_physical; /* physical offset in bytes for the start
-			      * of the extent */
-	__u64	fe_length;   /* length in bytes for the extent */
-	__u64	fe_reserved64[2];
-	__u32	fe_flags;    /* FIEMAP_EXTENT_* flags for this extent */
-	__u32	fe_reserved[3];
-};
+    struct fiemap_extent {
+	    __u64	fe_logical;  /* logical offset in bytes for the start of
+				* the extent */
+	    __u64	fe_physical; /* physical offset in bytes for the start
+				* of the extent */
+	    __u64	fe_length;   /* length in bytes for the extent */
+	    __u64	fe_reserved64[2];
+	    __u32	fe_flags;    /* FIEMAP_EXTENT_* flags for this extent */
+	    __u32	fe_reserved[3];
+    };
 
 All offsets and lengths are in bytes and mirror those on disk.  It is valid
 for an extents logical offset to start before the request or its logical
@@ -114,26 +116,27 @@ worry about all present and future flags which might imply unaligned
 data. Note that the opposite is not true - it would be valid for
 FIEMAP_EXTENT_NOT_ALIGNED to appear alone.
 
-* FIEMAP_EXTENT_LAST
-This is generally the last extent in the file. A mapping attempt past
-this extent may return nothing. Some implementations set this flag to
-indicate this extent is the last one in the range queried by the user
-(via fiemap->fm_length).
+FIEMAP_EXTENT_LAST
+  This is generally the last extent in the file. A mapping attempt past
+  this extent may return nothing. Some implementations set this flag to
+  indicate this extent is the last one in the range queried by the user
+  (via fiemap->fm_length).
 
-* FIEMAP_EXTENT_UNKNOWN
-The location of this extent is currently unknown. This may indicate
-the data is stored on an inaccessible volume or that no storage has
-been allocated for the file yet.
+FIEMAP_EXTENT_UNKNOWN
+  The location of this extent is currently unknown. This may indicate
+  the data is stored on an inaccessible volume or that no storage has
+  been allocated for the file yet.
 
-* FIEMAP_EXTENT_DELALLOC
-  - This will also set FIEMAP_EXTENT_UNKNOWN.
-Delayed allocation - while there is data for this extent, its
-physical location has not been allocated yet.
+FIEMAP_EXTENT_DELALLOC
+  This will also set FIEMAP_EXTENT_UNKNOWN.
 
-* FIEMAP_EXTENT_ENCODED
-This extent does not consist of plain filesystem blocks but is
-encoded (e.g. encrypted or compressed).  Reading the data in this
-extent via I/O to the block device will have undefined results.
+  Delayed allocation - while there is data for this extent, its
+  physical location has not been allocated yet.
+
+FIEMAP_EXTENT_ENCODED
+  This extent does not consist of plain filesystem blocks but is
+  encoded (e.g. encrypted or compressed).  Reading the data in this
+  extent via I/O to the block device will have undefined results.
 
 Note that it is *always* undefined to try to update the data
 in-place by writing to the indicated location without the
@@ -145,32 +148,32 @@ unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is
 clear; user applications must not try reading or writing to the
 filesystem via the block device under any other circumstances.
 
-* FIEMAP_EXTENT_DATA_ENCRYPTED
-  - This will also set FIEMAP_EXTENT_ENCODED
-The data in this extent has been encrypted by the file system.
+FIEMAP_EXTENT_DATA_ENCRYPTED
+  This will also set FIEMAP_EXTENT_ENCODED
+  The data in this extent has been encrypted by the file system.
 
-* FIEMAP_EXTENT_NOT_ALIGNED
-Extent offsets and length are not guaranteed to be block aligned.
+FIEMAP_EXTENT_NOT_ALIGNED
+  Extent offsets and length are not guaranteed to be block aligned.
 
-* FIEMAP_EXTENT_DATA_INLINE
+FIEMAP_EXTENT_DATA_INLINE
   This will also set FIEMAP_EXTENT_NOT_ALIGNED
-Data is located within a meta data block.
+  Data is located within a meta data block.
 
-* FIEMAP_EXTENT_DATA_TAIL
+FIEMAP_EXTENT_DATA_TAIL
   This will also set FIEMAP_EXTENT_NOT_ALIGNED
-Data is packed into a block with data from other files.
+  Data is packed into a block with data from other files.
 
-* FIEMAP_EXTENT_UNWRITTEN
-Unwritten extent - the extent is allocated but its data has not been
-initialized.  This indicates the extent's data will be all zero if read
-through the filesystem but the contents are undefined if read directly from
-the device.
+FIEMAP_EXTENT_UNWRITTEN
+  Unwritten extent - the extent is allocated but its data has not been
+  initialized.  This indicates the extent's data will be all zero if read
+  through the filesystem but the contents are undefined if read directly from
+  the device.
 
-* FIEMAP_EXTENT_MERGED
-This will be set when a file does not support extents, i.e., it uses a block
-based addressing scheme.  Since returning an extent for each block back to
-userspace would be highly inefficient, the kernel will try to merge most
-adjacent blocks into 'extents'.
+FIEMAP_EXTENT_MERGED
+  This will be set when a file does not support extents, i.e., it uses a block
+  based addressing scheme.  Since returning an extent for each block back to
+  userspace would be highly inefficient, the kernel will try to merge most
+  adjacent blocks into 'extents'.
 
 
 VFS -> File System Implementation
@@ -179,23 +182,23 @@ VFS -> File System Implementation
 File systems wishing to support fiemap must implement a ->fiemap callback on
 their inode_operations structure. The fs ->fiemap call is responsible for
 defining its set of supported fiemap flags, and calling a helper function on
-each discovered extent:
+each discovered extent::
 
-struct inode_operations {
+  struct inode_operations {
        ...
 
        int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start,
                      u64 len);
 
 ->fiemap is passed struct fiemap_extent_info which describes the
-fiemap request:
+fiemap request::
 
-struct fiemap_extent_info {
+  struct fiemap_extent_info {
 	unsigned int fi_flags;		/* Flags as passed from user */
 	unsigned int fi_extents_mapped;	/* Number of mapped extents */
 	unsigned int fi_extents_max;	/* Size of fiemap_extent array */
 	struct fiemap_extent *fi_extents_start;	/* Start of fiemap_extent array */
-};
+  };
 
 It is intended that the file system should not need to access any of this
 structure directly. Filesystem handlers should be tolerant to signals and return
@@ -203,9 +206,9 @@ EINTR once fatal signal received.
 
 
 Flag checking should be done at the beginning of the ->fiemap callback via the
-fiemap_check_flags() helper:
+fiemap_check_flags() helper::
 
-int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
+  int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
 
 The struct fieinfo should be passed in as received from ioctl_fiemap(). The
 set of fiemap flags which the fs understands should be passed via fs_flags. If
@@ -216,10 +219,10 @@ ioctl_fiemap().
 
 
 For each extent in the request range, the file system should call
-the helper function, fiemap_fill_next_extent():
+the helper function, fiemap_fill_next_extent()::
 
-int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical,
-			    u64 phys, u64 len, u32 flags, u32 dev);
+  int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical,
+			      u64 phys, u64 len, u32 flags, u32 dev);
 
 fiemap_fill_next_extent() will use the passed values to populate the
 next free extent in the fm_extents array. 'General' extent flags will
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index 8f26f1b91e04..c571112746f3 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -26,6 +26,7 @@ algorithms work.
    directory-locking
    devpts
    dnotify
+   fiemap
 
    automount-support
 
-- 
2.25.4


  parent reply	other threads:[~2020-04-27 21:17 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 21:16 [PATCH v3 00/29] Convert files to ReST - part 2 Mauro Carvalho Chehab
2020-04-27 21:16 ` Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 01/29] docs: filesystems: convert caching/object.txt to ReST Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 02/29] docs: filesystems: convert caching/fscache.txt to ReST format Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 03/29] docs: filesystems: caching/netfs-api.txt: convert it to ReST Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 04/29] docs: filesystems: caching/operations.txt: " Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 05/29] docs: filesystems: caching/cachefiles.txt: convert " Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 06/29] docs: filesystems: caching/backend-api.txt: convert it " Mauro Carvalho Chehab
2020-04-27 21:16 ` [PATCH v3 07/29] docs: filesystems: convert cifs/cifsroot.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 08/29] docs: filesystems: convert automount-support.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 09/29] docs: filesystems: convert coda.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 10/29] docs: filesystems: convert devpts.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 11/29] docs: filesystems: convert dnotify.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` Mauro Carvalho Chehab [this message]
2020-04-27 21:17 ` [PATCH v3 13/29] docs: filesystems: convert files.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 14/29] docs: filesystems: convert fuse-io.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 15/29] docs: filesystems: convert locks.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 16/29] docs: filesystems: convert mandatory-locking.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 17/29] docs: filesystems: convert mount_api.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 18/29] docs: filesystems: convert quota.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 19/29] docs: filesystems: convert seq_file.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 20/29] docs: filesystems: convert sharedsubtree.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 21/29] docs: filesystems: split spufs.txt into 3 separate files Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 22/29] docs: filesystems: convert spufs/spu_create.txt to ReST Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 23/29] docs: filesystems: convert spufs/spufs.txt " Mauro Carvalho Chehab
2020-04-27 21:17   ` Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 24/29] docs: filesystems: convert spufs/spu_run.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 25/29] docs: filesystems: convert sysfs-pci.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 26/29] docs: filesystems: convert sysfs-tagging.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 27/29] docs: filesystems: convert xfs-delayed-logging-design.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 28/29] docs: filesystems: convert xfs-self-describing-metadata.txt " Mauro Carvalho Chehab
2020-04-27 21:17 ` [PATCH v3 29/29] docs: filesystems: convert configfs.txt " Mauro Carvalho Chehab
2020-04-27 21:43   ` [PATCH v3.1] " Mauro Carvalho Chehab
2020-04-27 21:46     ` Joe Perches
2020-04-28 19:01 ` [PATCH v3 00/29] Convert files to ReST - part 2 Jonathan Corbet
2020-04-28 19:01   ` Jonathan Corbet
2020-04-28 19:25   ` Jan Harkes
2020-04-28 19:25     ` Jan Harkes
2020-05-05 15:28   ` Jonathan Corbet
2020-05-05 15:28     ` Jonathan Corbet

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=9182d49ffca7a0580e32ab24ecf5f8cc8d8924af.1588021877.git.mchehab+huawei@kernel.org \
    --to=mchehab+huawei@kernel.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.