On 09/21/2015 10:10 AM, Qu Wenruo wrote:
Just the same for mount time check, use new btrfs_check_degraded() to do
per chunk check.

Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com>
---
  fs/btrfs/super.c | 11 +++++++----
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index c389c13..720c044 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1681,11 +1681,14 @@ static int btrfs_remount(struct super_block *sb, int 
*flags, char *data)
                        goto restore;
                }

-               if (fs_info->fs_devices->missing_devices >
-                    fs_info->num_tolerated_disk_barrier_failures &&
-                   !(*flags & MS_RDONLY)) {
+               ret = btrfs_check_degradable(fs_info, *flags);
+               if (ret < 0) {
+                       btrfs_error(fs_info, ret,
+                                   "degraded writable remount failed");

btrfs_erorr() which is an error handling routine, isn't appropriate here, mainly because as we are in the remount context, I am not sure if you meant to change the fs state to readonly (on error) in the remount context ? or Instead btrfs_err() which is an error reporting/logging would be appropriate.

btrfs_erorr() and btrfs_err() are way different in action but very easy have an oversight and use the wrong one. the below patch changed it..

   Btrfs: consolidate btrfs_error() to btrfs_std_error()

Thanks, Anand


+                       goto restore;
+               } else if (ret > 0 && !btrfs_test_opt(root, DEGRADED)) {
                        btrfs_warn(fs_info,
-                               "too many missing devices, writeable remount is not 
allowed");
+                               "some device missing, but still degraded mountable, 
please remount with -o degraded option");
                        ret = -EACCES;
                        goto restore;
                }

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to