linux-kernel.vger.kernel.org archive mirror
 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 15/34] docs: filesystems: convert fiemap.txt to ReST
Date: Wed, 15 Apr 2020 16:32:28 +0200	[thread overview]
Message-ID: <efd1f1ff140d14042116900f9245ba3af015175b.1586960617.git.mchehab+huawei@kernel.org> (raw)
In-Reply-To: <cover.1586960617.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 960e0cc29491..5514fd122619 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -27,6 +27,7 @@ algorithms work.
    dax
    devpts
    dnotify
+   fiemap
 
    automount-support
 
-- 
2.25.2


  parent reply	other threads:[~2020-04-15 14:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 14:32 [PATCH 00/34] fs: convert remaining docs to ReST file format Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 01/34] docs: filesystems: fix references for doc files there Mauro Carvalho Chehab
2020-04-16  1:10   ` Joseph Qi
2020-04-15 14:32 ` [PATCH 02/34] docs: filesystems: convert caching/object.txt to ReST Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 03/34] docs: filesystems: convert caching/fscache.txt to ReST format Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 04/34] docs: filesystems: caching/netfs-api.txt: convert it to ReST Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 05/34] docs: filesystems: caching/operations.txt: " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 06/34] docs: filesystems: caching/cachefiles.txt: convert " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 07/34] docs: filesystems: caching/backend-api.txt: convert it " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 08/34] docs: filesystems: convert cifs/cifsroot.rst " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 09/34] docs: filesystems: convert configfs.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 10/34] docs: filesystems: convert automount-support.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 11/34] docs: filesystems: convert coda.txt " Mauro Carvalho Chehab
2020-04-15 15:08   ` Jan Harkes
2020-04-15 14:32 ` [PATCH 12/34] docs: filesystems: convert dax.txt " Mauro Carvalho Chehab
2020-04-15 15:41   ` Darrick J. Wong
2020-04-21 16:31     ` Mauro Carvalho Chehab
2020-04-21 18:31       ` Darrick J. Wong
2020-04-21 19:53         ` Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 13/34] docs: filesystems: convert devpts.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 14/34] docs: filesystems: convert dnotify.txt " Mauro Carvalho Chehab
2020-04-16  8:45   ` Jan Kara
2020-04-15 14:32 ` Mauro Carvalho Chehab [this message]
2020-04-15 14:32 ` [PATCH 16/34] docs: filesystems: convert files.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 17/34] docs: filesystems: convert fuse-io.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 18/34] docs: filesystems: convert gfs2-glocks.txt " Mauro Carvalho Chehab
2020-04-15 14:52   ` Andreas Gruenbacher
2020-04-15 14:32 ` [PATCH 19/34] docs: filesystems: convert locks.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 20/34] docs: filesystems: convert mandatory-locking.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 21/34] docs: filesystems: convert mount_api.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 22/34] docs: filesystems: rename path-lookup.txt file Mauro Carvalho Chehab
2020-04-16  2:00   ` Eric Biggers
2020-04-21 16:38     ` Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 23/34] docs: filesystems: convert path-walking.txt to ReST Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 24/34] docs: filesystems: convert quota.txt " Mauro Carvalho Chehab
2020-04-16  8:47   ` Jan Kara
2020-04-15 14:32 ` [PATCH 25/34] docs: filesystems: convert seq_file.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 26/34] docs: filesystems: convert sharedsubtree.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 27/34] docs: filesystems: split spufs.txt into 3 separate files Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 28/34] docs: filesystems: convert spufs/spu_create.txt to ReST Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 29/34] docs: filesystems: convert spufs/spufs.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 30/34] docs: filesystems: convert spufs/spu_run.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 31/34] docs: filesystems: convert sysfs-pci.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 32/34] docs: filesystems: convert sysfs-tagging.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 33/34] docs: filesystems: convert xfs-delayed-logging-design.txt " Mauro Carvalho Chehab
2020-04-15 14:32 ` [PATCH 34/34] docs: filesystems: convert xfs-self-describing-metadata.txt " Mauro Carvalho Chehab

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=efd1f1ff140d14042116900f9245ba3af015175b.1586960617.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 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).