btrfs-progs (4.4.1-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * New upstream release.
  * Rename package to btrfs-progs (Closes: #780081)
  * Update standards version to 3.9.7 (no changes needed).
  * debian/control: Add "Breaks" per Gianfranco Costamagna's suggestion
  * Change lintian override to reflect package rename
  * Switch from using postinst and postrm to using triggers
    per Christian Seiler's recommendation.

# imported from the archive

1 files changed, 90 insertions, 0 deletions

diff --git a/Documentation/btrfs-rescue.asciidoc b/Documentation/btrfs-rescue.asciidoc
new file mode 100644
index 00000000..42aca645
--- /dev/null
+++ b/Documentation/btrfs-rescue.asciidoc
@@ -0,0 +1,90 @@
+btrfs-rescue(8)
+==============
+
+NAME
+----
+btrfs-rescue - Recover a damaged btrfs filesystem
+
+SYNOPSIS
+--------
+*btrfs rescue* <subcommand> <args>
+
+DESCRIPTION
+-----------
+*btrfs rescue* is used to try to recover a damaged btrfs filesystem.
+
+SUBCOMMAND
+----------
+*chunk-recover* [options] <device>::
+Recover the chunk tree by scanning the devices
++
+`Options`
++
+-y::::
+assume an answer of 'yes' to all questions.
+-v::::
+verbose mode.
+-h::::
+help.
+
+NOTE: Since *chunk-recover* will scan the whole device, it will be *VERY* slow
+especially executed on a large device.
+
+*super-recover* [options] <device>::
+Recover bad superblocks from good copies.
++
+`Options`
++
+-y::::
+assume an answer of 'yes' to all questions.
+-v::::
+verbose mode.
+
+*zero-log* <device>::
+clear the filesystem log tree
+
+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 stacktraces that may show up in system log.
+
+The common case where this happens has been fixed a long time ago,
+so it is unlikely that you will see this particular problem, but the utility is
+kept around.
+
+NOTE: 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.
+
+One can determine whether *zero-log* is needed according to the kernel
+backtrace:
+----
+? 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]
+----
+
+If the errors are like above, then *zero-log* should be used to clear
+the log and the filesystem may be mounted normally again. The keywords to look
+for are 'open_ctree' which says that it's during mount and function names
+that contain 'replay', 'recover' or 'log_tree'.
+
+EXIT STATUS
+-----------
+*btrfs rescue* returns a zero exit status if it succeeds. Non zero is
+returned in case of failure.
+
+AVAILABILITY
+------------
+*btrfs* is part of btrfs-progs.
+Please refer to the btrfs wiki http://btrfs.wiki.kernel.org for
+further details.
+
+SEE ALSO
+--------
+`mkfs.btrfs`(8),
+`btrfs-scrub`(8),
+`btrfs-check`(8)