This may actually be a kernel timing bug. It appears that the partition
deletion ioctl call returns immediately, even though the kernel may
still have the device busy for a short time longer. The for loop spins
faster than the kernel can release the busy count on my platform. This
was not an issue for other, similar platforms, which seems to confirm
that this is a timing issue.
The attached patch fixes my issue, but this issue should probably be
demonstrated to someone in kernel land to verify. Frankly, I would
prefer that the ioctl function block until the partition is added or
removed, but there may be very good reasons why it doesn't.
Tony
#! /bin/sh -e
## retry-wait-on-busy.dpatch by Anthony Awtrey <[email protected]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Working around a timing issue in the kernel
. `dirname $0`/DPATCH
@DPATCH@
diff --urN a/libparted/arch/linux.c b/libparted/arch/linux.c
--- a/libparted/arch/linux.c
+++ b/libparted/arch/linux.c
@@ -2231,6 +2287,15 @@
for (i = 1; i <= last; i++) {
rets[i - 1] = _blkpg_remove_partition (disk, i);
errnums[i - 1] = errno;
+ /* HACK - if we get a busy let's wait for things to settle
from
+ * the previous delete and do a retry. Apparently the kernel
is
+ * returning before everything has completed.
+ */
+ if (!rets[i - 1] && errnums[i - 1] == EBUSY) {
+ sleep(1);
+ rets[i - 1] = _blkpg_remove_partition (disk, i);
+ errnums[i - 1] = errno;
+ }
}
for (i = 1; i <= last; i++) {
