From: Anand Jain <anand.jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.com
Subject: [PATCH v2 1/2] btrfs-progs: Documentation: fix sphinx code-block warning
Date: Wed, 10 Jan 2024 22:55:22 +0530 [thread overview]
Message-ID: <c3de4580548fcd242497a32c9062c5e1eb3eab7a.1704906806.git.anand.jain@oracle.com> (raw)
In-Reply-To: <cover.1704906806.git.anand.jain@oracle.com>
There are several warnings regarding the absence of an argument for the
code-block directive on some build servers using python3-sphinx 0.2.2-17.
For example:
Making all in Documentation
[SPHINX] man
ch-subvolume-intro.rst:141: WARNING: Error in "code-block" directive:
1 argument(s) required, 0 supplied.
.. code-block::
27 21 0:19 /subv1 /mnt rw,relatime - btrfs /dev/sda rw,space_cache
Etc...
Adding the none argument.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
Documentation/Tree-checker.rst | 4 ++--
Documentation/ch-subvolume-intro.rst | 2 +-
Documentation/dev/Developer-s-FAQ.rst | 2 +-
Documentation/dev/Experimental.rst | 4 ++--
Documentation/dev/dev-btrfs-design.rst | 8 ++++----
Documentation/trouble-index.rst | 16 ++++++++--------
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/Tree-checker.rst b/Documentation/Tree-checker.rst
index 68df6fdfa0de..620c203f098e 100644
--- a/Documentation/Tree-checker.rst
+++ b/Documentation/Tree-checker.rst
@@ -30,7 +30,7 @@ fine.
A message may look like:
-.. code-block::
+.. code-block:: none
[ 1716.823895] BTRFS critical (device vdb): corrupt leaf: root=18446744073709551607 block=38092800 slot=0, invalid key objectid: has 1 expect 6 or [256, 18446744073709551360] or 18446744073709551604
[ 1716.829499] BTRFS info (device vdb): leaf 38092800 gen 19 total ptrs 4 free space 15851 owner 18446744073709551607
@@ -54,7 +54,7 @@ checksum is found to be valid. This protects against changes to the metadata
that could possibly also update the checksum, less likely to happen accidentally
but rather due to intentional corruption or fuzzing.
-.. code-block::
+.. code-block:: none
[ 4823.612832] BTRFS critical (device vdb): corrupt leaf: root=7 block=30474240 slot=0, invalid nritems, have 0 should not be 0 for non-root leaf
[ 4823.616798] BTRFS error (device vdb): block=30474240 read time tree block corruption detected
diff --git a/Documentation/ch-subvolume-intro.rst b/Documentation/ch-subvolume-intro.rst
index 57b42fe7a97f..9ca39d0adba2 100644
--- a/Documentation/ch-subvolume-intro.rst
+++ b/Documentation/ch-subvolume-intro.rst
@@ -138,7 +138,7 @@ Mounting a read-write snapshot as read-only is possible and will not change the
The name of the mounted subvolume is stored in file :file:`/proc/self/mountinfo` in
the 4th column:
-.. code-block::
+.. code-block:: none
27 21 0:19 /subv1 /mnt rw,relatime - btrfs /dev/sda rw,space_cache
^^^^^^
diff --git a/Documentation/dev/Developer-s-FAQ.rst b/Documentation/dev/Developer-s-FAQ.rst
index 6d8d78e54b4d..496900415a67 100644
--- a/Documentation/dev/Developer-s-FAQ.rst
+++ b/Documentation/dev/Developer-s-FAQ.rst
@@ -178,7 +178,7 @@ For the next iteration, add a short description of the changes made, under the
first **---** (triple dash) marker in the patch. For example (see also Example
3):
-.. code-block::
+.. code-block:: none
---
V3: renamed variable
diff --git a/Documentation/dev/Experimental.rst b/Documentation/dev/Experimental.rst
index 4817faa56c79..70d14850f5c8 100644
--- a/Documentation/dev/Experimental.rst
+++ b/Documentation/dev/Experimental.rst
@@ -11,7 +11,7 @@ filed as issues.
In the code use it like:
-.. code-block::
+.. code-block:: none
if (EXPERIMENTAL) {
...
@@ -22,7 +22,7 @@ where it would break default build.
Or:
-.. code-block::
+.. code-block:: none
#if EXPERIMENTAL
...
diff --git a/Documentation/dev/dev-btrfs-design.rst b/Documentation/dev/dev-btrfs-design.rst
index c3a6d73872e9..befd30a114ba 100644
--- a/Documentation/dev/dev-btrfs-design.rst
+++ b/Documentation/dev/dev-btrfs-design.rst
@@ -15,7 +15,7 @@ The Btrfs btree provides a generic facility to store a variety of data
types. Internally it only knows about three data structures: keys,
items, and a block header:
-.. code-block::
+.. code-block:: none
struct btrfs_header {
u8 csum[32];
@@ -30,7 +30,7 @@ items, and a block header:
u8 level;
}
-.. code-block::
+.. code-block:: none
struct btrfs_disk_key {
__le64 objectid;
@@ -38,7 +38,7 @@ items, and a block header:
__le64 offset;
}
-.. code-block::
+.. code-block:: none
struct btrfs_item {
struct btrfs_disk_key key;
@@ -311,7 +311,7 @@ field of the root block may be different from the objectid of the
snapshot. So, when dropping references on tree roots, the objectid of
the root structure is always used. When a backref is deleted:
-.. code-block::
+.. code-block:: none
if backref was for a tree root:
root_objectid = root->root_key.objectid
diff --git a/Documentation/trouble-index.rst b/Documentation/trouble-index.rst
index 8de7d6232a11..4d07c85106fb 100644
--- a/Documentation/trouble-index.rst
+++ b/Documentation/trouble-index.rst
@@ -12,7 +12,7 @@ Error: parent transid verify error
Reason: result of a failed internal consistency check of the filesystem's metadata.
Type: permanent
-.. code-block::
+.. code-block:: none
[ 4007.489730] BTRFS error (device vdb): parent transid verify failed on 30736384 wanted 10 found 8
@@ -59,7 +59,7 @@ persisted and possibly making old copies available.
The most obvious way how to exhaust space is to create a file until the data
chunks are full:
-.. code-block::
+.. code-block:: none
$ df -h .
Filesystem Size Used Avail Use% Mounted on
@@ -98,7 +98,7 @@ action is possible. If not, ENOSPC is returned.
Error: unable to start balance with target metadata profile
-----------------------------------------------------------
-.. code-block::
+.. code-block:: none
unable to start balance with target metadata profile 32
@@ -111,7 +111,7 @@ Error: balance will reduce metadata integrity
The full message in system log
-.. code-block::
+.. code-block:: none
balance will reduce metadata integrity, use force if you want this
@@ -126,7 +126,7 @@ The preferred way is to use the :command:`wipefs` utility that is part of the
*util-linux* package. Running the command with the device will not destroy
the data, just list the detected filesystems:
-.. code-block::
+.. code-block:: none
# wipefs /dev/sda
offset type
@@ -137,7 +137,7 @@ the data, just list the detected filesystems:
Remove the filesystem signature at a given offset or wipe all recognized
signatures on the device:
-.. code-block::
+.. code-block:: none
# wipefs -o 0x10040 /dev/sda
8 bytes [5f 42 48 52 66 53 5f 4d] erased at offset 0x10040 (btrfs)
@@ -172,7 +172,7 @@ at 64MiB, the third one at 256GiB. The following lines reset the signature
on all the three copies:
-.. code-block::
+.. code-block:: none
# dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((64*1024+64))
# dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((64*1024*1024+64))
@@ -180,7 +180,7 @@ on all the three copies:
If you want to restore the super block signatures:
-.. code-block::
+.. code-block:: none
# echo "_BHRfS_M" | dd bs=1 count=8 of=/dev/sda seek=$((64*1024+64))
# echo "_BHRfS_M" | dd bs=1 count=8 of=/dev/sda seek=$((64*1024*1024+64))
--
2.31.1
next prev parent reply other threads:[~2024-01-10 17:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 17:25 [PATCH v2 0/2] btrfs-progs: Documentation: fix compile an error and Anand Jain
2024-01-10 17:25 ` Anand Jain [this message]
2024-01-10 17:25 ` [PATCH v2 2/2] btrfs-progs Documentation: placeholder for contents.rst file Anand Jain
2024-01-10 21:52 ` David Sterba
2024-01-11 4:20 ` Anand Jain
2024-01-11 4:21 ` [PATCH] btrfs-progs: fixup: v2 " Anand Jain
2024-01-11 16:05 ` David Sterba
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=c3de4580548fcd242497a32c9062c5e1eb3eab7a.1704906806.git.anand.jain@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@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.