Adding upstream version 4.22.0.upstream/4.22.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 195 insertions, 0 deletions

diff --git a/upstream/archlinux/man8/btrfs-rescue.8 b/upstream/archlinux/man8/btrfs-rescue.8
new file mode 100644
index 00000000..441e07c0
--- /dev/null
+++ b/upstream/archlinux/man8/btrfs-rescue.8
@@ -0,0 +1,195 @@
+.\" Man page generated from reStructuredText.
+.
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.TH "BTRFS-RESCUE" "8" "Feb 14, 2024" "6.7.1" "BTRFS"
+.SH NAME
+btrfs-rescue \- recover a damaged btrfs filesystem
+.SH SYNOPSIS
+.sp
+\fBbtrfs rescue\fP <subcommand> <args>
+.SH DESCRIPTION
+.sp
+\fBbtrfs rescue\fP is used to try to recover a damaged btrfs filesystem.
+.SH SUBCOMMAND
+.INDENT 0.0
+.TP
+.B chunk\-recover [options] <device>
+Recover the chunk tree by scanning the devices
+.sp
+\fBOptions\fP
+.INDENT 7.0
+.TP
+.B  \-y
+assume an answer of \fIyes\fP to all questions.
+.TP
+.B  \-h
+help.
+.TP
+.B  \-v
+(deprecated) alias for global \fI\-v\fP option
+.UNINDENT
+.UNINDENT
+.sp
+\fBNOTE:\fP
+.INDENT 0.0
+.INDENT 3.5
+Since \fBchunk\-recover\fP will scan the whole device, it will be very
+slow especially executed on a large device.
+.UNINDENT
+.UNINDENT
+.INDENT 0.0
+.TP
+.B fix\-device\-size <device>
+fix device size and super block total bytes values that do not match
+.sp
+Kernel 4.11 starts to check the device size more strictly and this might
+mismatch the stored value of total bytes. See the exact error message below.
+Newer kernel will refuse to mount the filesystem where the values do not match.
+This error is not fatal and can be fixed.  This command will fix the device
+size values if possible.
+.INDENT 7.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+BTRFS error (device sdb): super_total_bytes 92017859088384 mismatch with fs_devices total_rw_bytes 92017859094528
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+The mismatch may also exhibit as a kernel warning:
+.INDENT 7.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+WARNING: CPU: 3 PID: 439 at fs/btrfs/ctree.h:1559 btrfs_update_device+0x1c5/0x1d0 [btrfs]
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.UNINDENT
+.INDENT 0.0
+.TP
+.B clear\-ino\-cache <device>
+Remove leftover items pertaining to the deprecated \fIinode cache\fP feature.
+.sp
+The \fIinode cache\fP feature (enabled by mount option \(dqinode_cache\(dq) has been
+completely removed in 5.11 kernel.
+.TP
+.B clear\-space\-cache <v1|v2> <device>
+Completely remove the on\-disk data of free space cache of given version.
+.sp
+Especially for v1 free space cache, \fIclear_cache\fP mount option would only
+remove the cache for updated block groups, the remaining would not be removed.
+Thus this command is provided to manually clear the free space cache.
+.TP
+.B clear\-uuid\-tree <device>
+Clear UUID tree, so that kernel can re\-generate it at next read\-write
+mount.
+.sp
+Since kernel v4.16 there are more sanity check performed, and sometimes
+non\-critical trees like UUID tree can cause problems and reject the mount.
+In such case, clearing UUID tree may make the filesystem to be mountable again
+without much risk as it\(aqs built from other trees.
+.TP
+.B super\-recover [options] <device>
+Recover bad superblocks from good copies.
+.sp
+\fBOptions\fP
+.INDENT 7.0
+.TP
+.B  \-y
+assume an answer of \fIyes\fP to all questions.
+.TP
+.B  \-v
+(deprecated) alias for global \fI\-v\fP option
+.UNINDENT
+.TP
+.B zero\-log <device>
+clear the filesystem log tree
+.sp
+This command will clear the filesystem log tree. This may fix a specific
+set of problem when the filesystem mount fails due to the log replay. See below
+for sample stack traces that may show up in system log.
+.sp
+The common case where this happens was fixed a long time ago,
+so it is unlikely that you will see this particular problem, but the command is
+kept around.
+.sp
+\fBNOTE:\fP
+.INDENT 7.0
+.INDENT 3.5
+Clearing the log may lead to loss of changes that were made
+since the last transaction commit. This may be up to 30 seconds
+(default commit period) or less if the commit was implied by
+other filesystem activity.
+.UNINDENT
+.UNINDENT
+.sp
+One can determine whether \fBzero\-log\fP is needed according to the kernel
+backtrace:
+.INDENT 7.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+? replay_one_dir_item+0xb5/0xb5 [btrfs]
+? walk_log_tree+0x9c/0x19d [btrfs]
+? btrfs_read_fs_root_no_radix+0x169/0x1a1 [btrfs]
+? btrfs_recover_log_trees+0x195/0x29c [btrfs]
+? replay_one_dir_item+0xb5/0xb5 [btrfs]
+? btree_read_extent_buffer_pages+0x76/0xbc [btrfs]
+? open_ctree+0xff6/0x132c [btrfs]
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+If the errors are like above, then \fBzero\-log\fP should be used to clear
+the log and the filesystem may be mounted normally again. The keywords to look
+for are \(aqopen_ctree\(aq which says that it\(aqs during mount and function names
+that contain \fIreplay\fP, \fIrecover\fP or \fIlog_tree\fP\&.
+.UNINDENT
+.SH EXIT STATUS
+.sp
+\fBbtrfs rescue\fP returns a zero exit status if it succeeds. Non zero is
+returned in case of failure.
+.SH AVAILABILITY
+.sp
+\fBbtrfs\fP is part of btrfs\-progs.  Please refer to the documentation at
+\fI\%https://btrfs.readthedocs.io\fP\&.
+.SH SEE ALSO
+.sp
+\fI\%btrfs\-check(8)\fP,
+\fI\%btrfs\-scrub(8)\fP,
+\fI\%mkfs.btrfs(8)\fP
+.\" Generated by docutils manpage writer.
+.