On Mon, Oct 13, 2014 at 06:18:04PM +0800, Anand Jain wrote:
>
>
> On 10/13/14 14:59, Eryu Guan wrote:
> >On Mon, Oct 13, 2014 at 02:23:57PM +0800, Anand Jain wrote:
> >>
> >>
> >>comments below..
> >>
> >>
> >>On 10/13/14 12:42, Eryu Guan wrote:
> >>>device replace could fail due to another running scrub process or any
> >>>other errors btrfs_scrub_dev() may hit, but this failure doesn't get
> >>>returned to userspace.
> >>>
> >>>The following steps could reproduce this issue
> >>>
> >>> mkfs -t btrfs -f /dev/sdb1 /dev/sdb2
> >>> mount /dev/sdb1 /mnt/btrfs
> >>> while true; do btrfs scrub start -B /mnt/btrfs >/dev/null 2>&1; done &
> >>> btrfs replace start -Bf /dev/sdb2 /dev/sdb3 /mnt/btrfs
> >>> # if this replace succeeded, do the following and repeat until
> >>> # you see this log in dmesg
> >>> # BTRFS: btrfs_scrub_dev(/dev/sdb2, 2, /dev/sdb3) failed -115
> >>> #btrfs replace start -Bf /dev/sdb3 /dev/sdb2 /mnt/btrfs
> >>>
> >>> # once you see the error log in dmesg, check return value of
> >>> # replace
> >>> echo $?
> >>>
> >>>Introduce a new dev replace result
> >>>
> >>>BTRFS_IOCTL_DEV_REPLACE_RESULT_SCRUB_INPROGRESS
> >>>
> >>>to catch -EINPROGRESS explicitly and return other errors directly to
> >>>userspace.
> >>>
> >>>Signed-off-by: Eryu Guan <guane...@gmail.com>
> >>>---
> >>>
> >>>v2:
> >>>- set result to SCRUB_INPROGRESS if btrfs_scrub_dev returned -EINPROGRESS
> >>> and return 0 as Miao Xie suggested
> >>>
> >>> fs/btrfs/dev-replace.c | 12 +++++++++---
> >>> include/uapi/linux/btrfs.h | 1 +
> >>> 2 files changed, 10 insertions(+), 3 deletions(-)
> >>>
> >>>diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
> >>>index eea26e1..a141f8b 100644
> >>>--- a/fs/btrfs/dev-replace.c
> >>>+++ b/fs/btrfs/dev-replace.c
> >>>@@ -418,9 +418,15 @@ int btrfs_dev_replace_start(struct btrfs_root *root,
> >>> &dev_replace->scrub_progress, 0, 1);
> >>>
> >>> ret = btrfs_dev_replace_finishing(root->fs_info, ret);
> >>>- WARN_ON(ret);
> >>>+ /* don't warn if EINPROGRESS, someone else might be running scrub */
> >>>+ if (ret == -EINPROGRESS) {
> >>>+ args->result = BTRFS_IOCTL_DEV_REPLACE_RESULT_SCRUB_INPROGRESS;
> >>>+ ret = 0;
> >>>+ } else {
> >>>+ WARN_ON(ret);
> >>>+ }
>
>
> I am bit concerned, why these racing threads here aren't excluding
> each other using "mutually_exclusive_operation_running" ? as most
> of the other device operation thread does.
>
> Thanks, Anand
btrfs_ioctl_scrub() doesn't use mutually_exclusive_operation_running
as other device operations do, I'm not sure if it should(seems scrub
should do it too to me).
But I think that's a different problem from the one I'm trying to fix
here. The main purpose is to return error to userspace when
btrfs_scrub_dev() hit some error. Dealing with -EINPROGRESS is to
match the current behavior(replace and scrub could run at the same
time).
Thanks,
Eryu
>
> >> looks like was are trying to manage EINPROGRESS returned by
> >
> >Yes, that's right.
> >
> >> btrfs_dev_replace_finishing(). In btrfs_dev_replace_finishing()
> >> which specific func call is returning EINPROGRESS ? I didn't go
> >> deep enough.
> >
> >btrfs_dev_replace_finishing() will check the scrub_ret(the last
> >argument), and return scrub_ret if (!scrub_ret). It was returning 0
> >unconditionally before this patch.
> >
> >btrfs_dev_replace_start@fs/btrfs/dev-replace.c
> > 416 ret = btrfs_scrub_dev(fs_info, src_device->devid, 0,
> > 417 src_device->total_bytes,
> > 418 &dev_replace->scrub_progress, 0, 1);
> > 419
> > 420 ret = btrfs_dev_replace_finishing(root->fs_info, ret);
> >
> >and btrfs_dev_replace_finishing@fs/btrfs/dev-replace.c
> > 529 if (!scrub_ret) {
> > 530
> > btrfs_dev_replace_update_device_in_mapping_tree(fs_info,
> > 531
> > src_device,
> > 532
> > tgt_device);
> > 533 } else {
> >......
> > 547 return scrub_ret;
> > 548 }
>
>
>
>
>
> >>
> >> And how do we handle if replace is intervened by balance
> >> instead of scrub ?
> >
> >Based on my test, replace ioctl would return -ENOENT if balance is
> >running
> >
> >ERROR: ioctl(DEV_REPLACE_START) failed on "/mnt/testarea/scratch": No such
> >file or directory, no error
> >
> >(I haven't gone through this codepath yet and don't know where -ENOENT
> >comes from, but I don't think it's a proper errno,
> >/mnt/testarea/scratch is definitely there)
> >>
> >> sorry if I missed something.
> >>
> >>Anand
> >
> >Thanks for the review!
> >
> >Eryu
> >>
> >>
> >>>- return 0;
> >>>+ return ret;
> >>>
> >>> leave:
> >>> dev_replace->srcdev = NULL;
> >>>@@ -538,7 +544,7 @@ static int btrfs_dev_replace_finishing(struct
> >>>btrfs_fs_info *fs_info,
> >>> btrfs_destroy_dev_replace_tgtdev(fs_info, tgt_device);
> >>> mutex_unlock(&dev_replace->lock_finishing_cancel_unmount);
> >>>
> >>>- return 0;
> >>>+ return scrub_ret;
> >>> }
> >>>
> >>> printk_in_rcu(KERN_INFO
> >>>diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
> >>>index 2f47824..611e1c5 100644
> >>>--- a/include/uapi/linux/btrfs.h
> >>>+++ b/include/uapi/linux/btrfs.h
> >>>@@ -157,6 +157,7 @@ struct btrfs_ioctl_dev_replace_status_params {
> >>> #define BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_ERROR 0
> >>> #define BTRFS_IOCTL_DEV_REPLACE_RESULT_NOT_STARTED 1
> >>> #define BTRFS_IOCTL_DEV_REPLACE_RESULT_ALREADY_STARTED 2
> >>>+#define BTRFS_IOCTL_DEV_REPLACE_RESULT_SCRUB_INPROGRESS 3
> >>> struct btrfs_ioctl_dev_replace_args {
> >>> __u64 cmd; /* in */
> >>> __u64 result; /* out */
> >>>
--
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
