From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: Coly Li <colyli@suse.de>, linux-raid@vger.kernel.org
Subject: Re: [PATCH v5] Incremental: remove obsoleted calls to udisks
Date: Mon, 4 Sep 2023 09:48:32 +0200 [thread overview]
Message-ID: <20230904094832.000033a7@linux.intel.com> (raw)
In-Reply-To: <3dddeea7-cfda-63d3-7169-e42ef05f9467@trained-monkey.org>
On Fri, 1 Sep 2023 11:47:09 -0400
Jes Sorensen <jes@trained-monkey.org> wrote:
> On 8/13/23 12:46, Coly Li wrote:
> > Utility udisks is removed from udev upstream, calling this obsoleted
> > command in run_udisks() doesn't make any sense now.
> >
> > This patch removes the calls chain of udisks, which includes routines
> > run_udisk(), force_remove(), and 2 locations where force_remove() are
> > called. Considering force_remove() is removed with udisks util, it is
> > fair to remove Manage_stop() inside force_remove() as well.
> >
> > In the two modifications where calling force_remove() are removed,
> > the failure from Manage_subdevs() can be safely ignored, because,
> > 1) udisks doesn't exist, no need to check the return value to umount
> > the file system by udisks and remove the component disk again.
> > 2) After the 'I' inremental remove, there is another 'r' hot remove
> > following up. The first incremental remove is a best-try effort.
> >
> > Therefore in this patch, where force_remove() is removed, the return
> > value of calling Manage_subdevs() is not checked too.
> >
> > Signed-off-by: Coly Li <colyli@suse.de>
> > Reviewed-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
> > Cc: Jes Sorensen <jes@trained-monkey.org>
> > ---
> > Changelog,
> > v5: change Mariusz's email address as he suggested
> > v4: add Reviewed-by from Mariusz.
> > v3: remove the almost-useless warning message, and make the change
> > more simplified.
> > v2: improve based on code review comments from Mariusz.
> > v1: initial version.
> >
> > Incremental.c | 64 +++++++++++----------------------------------------
> > 1 file changed, 13 insertions(+), 51 deletions(-)
>
> Been out of the loop for a while, trying to catch up.
>
> Mariusz, do you consider this one good to go now? You were the one
> providing feedback multiple times.
>
> Thanks,
> Jes
>
>
Hi Jes,
Yes, I see this as a good change. The current behavior is not stable, because
udev is not able to "umount"- if array is not mounted it is stopped, otherwise
not.
With the change, we will not try to stop it at all- fair for me, behavior is
same every time. If we cannot stop array every time we should not try to.
Thanks,
Mariusz
next prev parent reply other threads:[~2023-09-04 7:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-13 16:46 [PATCH v5] Incremental: remove obsoleted calls to udisks Coly Li
2023-09-01 15:47 ` Jes Sorensen
2023-09-04 7:48 ` Mariusz Tkaczyk [this message]
2023-10-26 21:37 ` Jes Sorensen
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=20230904094832.000033a7@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=colyli@suse.de \
--cc=jes@trained-monkey.org \
--cc=linux-raid@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.