diff options
| -rw-r--r-- | Documentation/btrfs-rescue.asciidoc | 24 | ||||
| -rw-r--r-- | Documentation/btrfs-zero-log.asciidoc | 45 |
2 files changed, 16 insertions, 53 deletions
diff --git a/Documentation/btrfs-rescue.asciidoc b/Documentation/btrfs-rescue.asciidoc index 32d8a927..42aca645 100644 --- a/Documentation/btrfs-rescue.asciidoc +++ b/Documentation/btrfs-rescue.asciidoc @@ -1,4 +1,4 @@ -btrfs-check(8) +btrfs-rescue(8) ============== NAME @@ -41,15 +41,21 @@ assume an answer of 'yes' to all questions. verbose mode. *zero-log* <device>:: -clear out log tree +clear the filesystem log tree -*btrfs rescue zero-log* will remove the log tree if log tree is corrupt, which -will allow you to mount the filesystem again. +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. +so it is unlikely that you will see this particular problem, but the utility is +kept around. -One can determine whether *btrfs-zero-log* is needed according to the kernel +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] @@ -61,8 +67,10 @@ backtrace: ? open_ctree+0xff6/0x132c [btrfs] ---- -If the errors are like above, then *zero-log* could be used to clear -the log and the filesystem may be mounted normally again. +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 ----------- diff --git a/Documentation/btrfs-zero-log.asciidoc b/Documentation/btrfs-zero-log.asciidoc deleted file mode 100644 index 498ecd67..00000000 --- a/Documentation/btrfs-zero-log.asciidoc +++ /dev/null @@ -1,45 +0,0 @@ -btrfs-zero-log(8) -================= - -NAME ----- -btrfs-zero-log - clear out log tree - -SYNOPSIS --------- -*btrfs-zero-log* <dev> - -DESCRIPTION ------------ -*btrfs-zero-log* will remove the log tree if log tree is corrupt, which will -allow you to mount the filesystem again. - -The common case where this happens has been fixed a long time ago, -so it is unlikely that you will see this particular problem. - -One can determine whether *btrfs-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 *btrfs-zero-log* should be used to clear -the log and the filesystem may be mounted normally again. - -NOTE: If you use btrfs as the root filesystem, you may want to include -*btrfs-zero-log* into initramdisk if the log problems hits you often. - -EXIT STATUS ------------ -*btrfs-zero-log* will return 0 if no error happened. -Other exit code means some problems happened. - -SEE ALSO --------- -`mkfs.btrfs`(8) |