linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xiao Ni <xni@redhat.com>
To: Phillip Susi <phill@thesusis.net>
Cc: linux-raid <linux-raid@vger.kernel.org>,
	Heinz Mauelshagen <heinzm@redhat.com>,
	Nigel Croxon <ncroxon@redhat.com>
Subject: Re: The raid device can't be unmount when it can't work
Date: Wed, 4 Nov 2020 10:42:25 +0800	[thread overview]
Message-ID: <f51a8b6a-4da7-ca0a-ac35-8bc478c64ada@redhat.com> (raw)
In-Reply-To: <87tuu7y0vq.fsf@vps.thesusis.net>



On 11/03/2020 04:11 AM, Phillip Susi wrote:
> Xiao Ni writes:
>
>> When one raid loses disks that are bigger than the max degraded number,
>> the udev rule[1] tries to stop
>> the raid device. If the raid device is mount, it tries to unmount it
> Why?  If there are open files on it, you won't be able to unmount it
> anyway, and what would you gain by stopping the broken device?
Hi Phillip

This policy was introduced by this patch:

commit 8af530b07fce27f56c56b2ffd254a40b4ab67c6b
Author: NeilBrown <neilb@suse.de>
Date:   Tue Mar 5 09:46:34 2013 +1100

     Enhance incremental removal.

     When asked to incrementally-remove a device, try marking the array
     read-auto first.  That will delay recording the failure in the
     metadata until it is really relevant.
     This way, if the device are just unplugged when the array is not
     really in use, the metadata will remain clean.

     If marking the default as faulty fails because it is EBUSY, that
     implies that the array would be failed without the device.  As the
     device has (presumably gone) - that means the array is dead.  So try
     to stop it.  If that fails because it is in use, send a uevent to
     report that it is gone.  Hopefully whoever mounted it will now let go.

     This means that if  you plug in some devices and they are
     auto-assembled, then unplugging them will auto-deassemble relatively
     cleanly.

     To be complete, we really need the kernel to disassemble the array
     after the last close somehow.  Maybe if a REMOVE has failed and a STOP
     has failed and nothing else much has happened, it could safely stop
     the array on last close.

>
>> first[2]. It uses udisks command to do this.
>> It's a little old. Now the package version is udisks2 which uses
>> udisksctl to do this. I write a patch[3] and do
>> test. It's failed because of "udisksctl error Permission denied".
> Udisks is a GNOME desktop component, and so may not even exist on many
> systems.  When it does, you still can't call it from udev scripts since
> they are not run within the desktop in the context of a logged in user.
> If you want to unmount the device, just use umount.
>
Thanks for sharing the knowledge.

Regards
Xiao


  reply	other threads:[~2020-11-04  2:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-30 12:38 The raid device can't be unmount when it can't work Xiao Ni
2020-10-31  0:49 ` Xiao Ni
2020-11-02 20:11 ` Phillip Susi
2020-11-04  2:42   ` Xiao Ni [this message]
2020-11-04  2:51     ` Xiao Ni

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=f51a8b6a-4da7-ca0a-ac35-8bc478c64ada@redhat.com \
    --to=xni@redhat.com \
    --cc=heinzm@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=ncroxon@redhat.com \
    --cc=phill@thesusis.net \
    /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).