* The raid device can't be unmount when it can't work
@ 2020-10-30 12:38 Xiao Ni
2020-10-31 0:49 ` Xiao Ni
2020-11-02 20:11 ` Phillip Susi
0 siblings, 2 replies; 5+ messages in thread
From: Xiao Ni @ 2020-10-30 12:38 UTC (permalink / raw)
To: linux-raid; +Cc: Heinz Mauelshagen, Nigel Croxon
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
Hi all
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
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".
The first test:
[root@localhost ~]# mdadm -CR /dev/md0 -l5 -n3 /dev/sdg /dev/sdi
/dev/sdj --assume-clean
[root@localhost ~]# mkfs.xfs /dev/md0
[root@localhost ~]# mount /dev/md0 /mnt/test/
[root@localhost ~]# mdadm -If sdg
mdadm: set sdg faulty in md0
mdadm: hot removed sdg from md0
[root@localhost ~]# mdadm -If sdi
mdadm: set device faulty failed for sdi: Device or resource busy
Unmounted /dev/md0.
The patch works as expected.
The second test:
[root@localhost ~]# mdadm -CR /dev/md0 -l5 -n3 /dev/sdg /dev/sdi
/dev/sdj --assume-clean
[root@localhost ~]# mkfs.xfs /dev/md0
[root@localhost ~]# mount /dev/md0 /mnt/test/
[root@localhost ~]# echo "scsi remove-single-device 6 0 0 0" >
/proc/scsi/scsi
[root@localhost ~]# echo "scsi remove-single-device 7 0 0 0" >
/proc/scsi/scsi
The /dev/md0 is still mount. The patch doesn't work as expected. Logs
are added during the test. It reports
error "udisksctl error Permission denied"
I searched in google to find the reason. It says it needs to config
polkit[4]. I did but it didn't work.
The patch is in the attachment
[1]: udev-md-raid-assembly.rules
[2]: IncrementalRemove->force_remove
[3]: The patch is in the attachment
[4]: https://github.com/coldfix/udiskie/wiki/Permissions
Best Regards
Xiao
[-- Attachment #2: 0001-change-udisks-to-udisksctl.patch --]
[-- Type: text/x-patch, Size: 1259 bytes --]
From 0e5b3833da9ba3b663224daf91eb67e8b55a31c4 Mon Sep 17 00:00:00 2001
From: Xiao Ni <xni@redhat.com>
Date: Mon, 26 Oct 2020 23:21:10 +0800
Subject: [PATCH 1/1] mdadm/Incremental: change udisks to udisksctl
Signed-off-by: Xiao Ni <xni@redhat.com>
---
Incremental.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Incremental.c b/Incremental.c
index 98dbcd9..64c9b48 100644
--- a/Incremental.c
+++ b/Incremental.c
@@ -1679,8 +1679,8 @@ static void run_udisks(char *arg1, char *arg2)
int pid = fork();
int status;
if (pid == 0) {
- execl("/usr/bin/udisks", "udisks", arg1, arg2, NULL);
- execl("/bin/udisks", "udisks", arg1, arg2, NULL);
+ execl("/usr/bin/udisksctl", "udisksctl", arg1, "-b", arg2, NULL);
+ execl("/bin/udisksctl", "udisksctl", arg1, "-b", arg2, NULL);
exit(1);
}
while (pid > 0 && wait(&status) != pid)
@@ -1692,7 +1692,7 @@ static int force_remove(char *devnm, int fd, struct mdinfo *mdi, int verbose)
int rv;
int devid = devnm2devid(devnm);
- run_udisks("--unmount", map_dev(major(devid), minor(devid), 0));
+ run_udisks("unmount", map_dev(major(devid), minor(devid), 0));
rv = Manage_stop(devnm, fd, verbose, 1);
if (rv) {
/* At least we can try to trigger a 'remove' */
--
2.7.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: The raid device can't be unmount when it can't work
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
1 sibling, 0 replies; 5+ messages in thread
From: Xiao Ni @ 2020-10-31 0:49 UTC (permalink / raw)
To: linux-raid; +Cc: Heinz Mauelshagen, Nigel Croxon
For convenient, paste the patch here:
diff --git a/Incremental.c b/Incremental.c
index 98dbcd9..64c9b48 100644
--- a/Incremental.c
+++ b/Incremental.c
@@ -1679,8 +1679,8 @@ static void run_udisks(char *arg1, char *arg2)
int pid = fork();
int status;
if (pid == 0) {
- execl("/usr/bin/udisks", "udisks", arg1, arg2, NULL);
- execl("/bin/udisks", "udisks", arg1, arg2, NULL);
+ execl("/usr/bin/udisksctl", "udisksctl", arg1, "-b", arg2, NULL);
+ execl("/bin/udisksctl", "udisksctl", arg1, "-b", arg2, NULL);
exit(1);
}
while (pid > 0 && wait(&status) != pid)
@@ -1692,7 +1692,7 @@ static int force_remove(char *devnm, int fd, struct mdinfo *mdi, int verbose)
int rv;
int devid = devnm2devid(devnm);
- run_udisks("--unmount", map_dev(major(devid), minor(devid), 0));
+ run_udisks("unmount", map_dev(major(devid), minor(devid), 0));
rv = Manage_stop(devnm, fd, verbose, 1);
if (rv) {
/* At least we can try to trigger a 'remove' */
----- Original Message -----
> From: "Xiao Ni" <xni@redhat.com>
> To: "linux-raid" <linux-raid@vger.kernel.org>
> Cc: "Heinz Mauelshagen" <heinzm@redhat.com>, "Nigel Croxon" <ncroxon@redhat.com>
> Sent: Friday, October 30, 2020 8:38:16 PM
> Subject: The raid device can't be unmount when it can't work
>
> Hi all
>
> 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
> 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".
>
> The first test:
> [root@localhost ~]# mdadm -CR /dev/md0 -l5 -n3 /dev/sdg /dev/sdi
> /dev/sdj --assume-clean
> [root@localhost ~]# mkfs.xfs /dev/md0
> [root@localhost ~]# mount /dev/md0 /mnt/test/
> [root@localhost ~]# mdadm -If sdg
> mdadm: set sdg faulty in md0
> mdadm: hot removed sdg from md0
> [root@localhost ~]# mdadm -If sdi
> mdadm: set device faulty failed for sdi: Device or resource busy
> Unmounted /dev/md0.
>
> The patch works as expected.
>
> The second test:
> [root@localhost ~]# mdadm -CR /dev/md0 -l5 -n3 /dev/sdg /dev/sdi
> /dev/sdj --assume-clean
> [root@localhost ~]# mkfs.xfs /dev/md0
> [root@localhost ~]# mount /dev/md0 /mnt/test/
> [root@localhost ~]# echo "scsi remove-single-device 6 0 0 0" >
> /proc/scsi/scsi
> [root@localhost ~]# echo "scsi remove-single-device 7 0 0 0" >
> /proc/scsi/scsi
> The /dev/md0 is still mount. The patch doesn't work as expected. Logs
> are added during the test. It reports
> error "udisksctl error Permission denied"
>
> I searched in google to find the reason. It says it needs to config
> polkit[4]. I did but it didn't work.
>
> The patch is in the attachment
> [1]: udev-md-raid-assembly.rules
> [2]: IncrementalRemove->force_remove
> [3]: The patch is in the attachment
> [4]: https://github.com/coldfix/udiskie/wiki/Permissions
>
> Best Regards
> Xiao
>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: The raid device can't be unmount when it can't work
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
1 sibling, 1 reply; 5+ messages in thread
From: Phillip Susi @ 2020-11-02 20:11 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, Heinz Mauelshagen, Nigel Croxon
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?
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The raid device can't be unmount when it can't work
2020-11-02 20:11 ` Phillip Susi
@ 2020-11-04 2:42 ` Xiao Ni
2020-11-04 2:51 ` Xiao Ni
0 siblings, 1 reply; 5+ messages in thread
From: Xiao Ni @ 2020-11-04 2:42 UTC (permalink / raw)
To: Phillip Susi; +Cc: linux-raid, Heinz Mauelshagen, Nigel Croxon
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The raid device can't be unmount when it can't work
2020-11-04 2:42 ` Xiao Ni
@ 2020-11-04 2:51 ` Xiao Ni
0 siblings, 0 replies; 5+ messages in thread
From: Xiao Ni @ 2020-11-04 2:51 UTC (permalink / raw)
To: Phillip Susi; +Cc: linux-raid, Heinz Mauelshagen, Nigel Croxon
On 11/04/2020 10:42 AM, Xiao Ni wrote:
>
>
> 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.
And this patch:
commit 6b63c1a4570412c06a40ffa57d35577816259a94
Author: NeilBrown <neilb@suse.de>
Date: Mon May 13 12:07:40 2013 +1000
Incrmental: tell udevs to unmount when array looks to have disappeared.
If a device is removed which appears to be busy in an md array, then
it is very like the array cannot be used.
We currently try to stop it, but that could fail if udisks had
automatically mounted it.
So tell udisks to unmount it, but ignore any error.
>
>>
>>> 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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-04 2:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2020-11-04 2:51 ` Xiao Ni
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.