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
next prev 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).