From: anand jain <anand.jain@oracle.com>
To: Stefan Behrens <sbehrens@giantdisaster.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: introduce BTRFS_IOC_CHECK_DEV_EXCL_OPS ioctl to check dev excl op
Date: Thu, 22 Aug 2013 17:51:37 +0800 [thread overview]
Message-ID: <5215DF29.3030100@oracle.com> (raw)
In-Reply-To: <5214C78C.3030001@giantdisaster.de>
Thanks for reviewing. Comments below.
> IMHO this is just a workaround for a design flaw.
Its a simple fix on the lines of current design.
> Now it is like this (in the replace CLI without the "do not background"
> option):
> 1. in user mode, check that the ioctl will succeed, exit with failure if
> the checks fail
> 2. fork
> 3. exit(0) the parent
> 4. the backgrounded child executes the ioctl, the result is _ignored_
> 5. the user _has to_ check the status (progress, completion, errors) by
> calling 'btrfs replace status' which can optionally block until the
> replace procedure is finished, or optionally periodically print the
> status. The exit value of 'btrfs replace status' is set depending on
> whether there had been errors.
Yes thats the current design.
> Step #1 is incomplete and can never be complete due to race conditions
> and because the checks in the kernel could be enhanced without updating
> the progs. Your patch is trying to improve step #1, to keep up with the
> checks in the kernel code.
its an overhead, something like design drawback
> With the "do not background" option for btrfs replace it looks like this:
> 1. check that the ioctl will succeed (just because the code is shared
> with the case that the "do not background" option is not set)
> 2. execute the ioctl, the result is used to generate error messages and
> to build the exit code, the process does not terminate before the
> procedure is finished
> 3. the user _can_ check the status (progress, completion, errors) by
> calling 'btrfs replace status'
Ok. Code can be bit optimized.
> I'd prefer it like this in both cases:
> 1. execute the ioctl (don't check anything in user mode before), set a
> flag whether the "do not background" option is set
> 2. in the kernel code inside the ioctl, perform all checks until there
> is no more regular reason to fail
> 3. in case of errors, return from the ioctl with an error code
> 4. if backgrounding was requested, return from the ioctl indicating that
> all checks had succeeded
> 5. if the ioctl failed, print an error message and set the exit value
> accordingly
> 6. if the ioctl succeeded and backgrounding was requested, background in
> user mode and call the ioctl again, this time with the "do not
> background" option
> This way we would still have the issue with the possible race, but at
> least the checks would be done only in one place. And the additional
> ioctl(CHECK_DEV_EXCL_OPS) would be avoided.
yeah this can be done for the long term it helps to reduce the
overhead of maintaining two similar codes. But CHECK_DEV_EXCL_OPS
helps to solve an easily seen bug[1] with minimal impact.
Further CHECK_DEV_EXCL_OPS will be useful to fix issues with
other cross vol operations.
[1]
test case:
terminal1: Run balance;
terminal2: Run replace (without -B)
problem: though replace fails, its unreported
Thanks, Anand
next prev parent reply other threads:[~2013-08-22 9:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 13:10 [PATCH] btrfs: introduce BTRFS_IOC_CHECK_DEV_EXCL_OPS ioctl to check dev excl op Anand Jain
2013-08-21 13:10 ` [PATCH] btrfs-progs: replace fails start but in the background Anand Jain
2013-09-02 2:55 ` [PATCH] btrfs-progs: replace fails start but in the background v2 Anand Jain
2013-09-06 9:39 ` Anand Jain
2013-09-06 9:38 ` [PATCH] btrfs-progs: replace fails start but in the background Anand Jain
2013-08-21 13:58 ` [PATCH] btrfs: introduce BTRFS_IOC_CHECK_DEV_EXCL_OPS ioctl to check dev excl op Stefan Behrens
2013-08-22 9:51 ` anand jain [this message]
2013-08-22 10:36 ` Stefan Behrens
2013-08-23 6:45 ` Anand Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5215DF29.3030100@oracle.com \
--to=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sbehrens@giantdisaster.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).