From d78d642bffff6ea49d62c19f26052ed6d3dcc467 Mon Sep 17 00:00:00 2001 From: Dimitri John Ledkov Date: Thu, 11 Jan 2018 15:44:55 +0000 Subject: New upstream release. --- Documentation/btrfs-rescue.asciidoc | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) (limited to 'Documentation/btrfs-rescue.asciidoc') diff --git a/Documentation/btrfs-rescue.asciidoc b/Documentation/btrfs-rescue.asciidoc index 24b619c6..743a23a6 100644 --- a/Documentation/btrfs-rescue.asciidoc +++ b/Documentation/btrfs-rescue.asciidoc @@ -15,6 +15,7 @@ DESCRIPTION SUBCOMMAND ---------- + *chunk-recover* [options] :: Recover the chunk tree by scanning the devices + @@ -30,6 +31,25 @@ help. NOTE: Since *chunk-recover* will scan the whole device, it will be *VERY* slow especially executed on a large device. +*fix-device-size* :: +fix device size and super block total bytes values that are do not match ++ +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. ++ +---- +BTRFS error (device sdb): super_total_bytes 92017859088384 mismatch with fs_devices total_rw_bytes 92017859094528 +---- ++ +The mismatch may also exhibit as a kernel warning: ++ +---- +WARNING: CPU: 3 PID: 439 at fs/btrfs/ctree.h:1559 btrfs_update_device+0x1c5/0x1d0 [btrfs] +---- + *super-recover* [options] :: Recover bad superblocks from good copies. + @@ -47,8 +67,8 @@ 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 +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. + NOTE: clearing the log may lead to loss of changes that were made since the -- cgit v1.2.3