On Tue, Jan 19, 2010 at 01:26:32PM -0700, Curtis Gedak wrote: > Petr Uzel wrote: > >if this udev change is the cause of the resizing problem, then it is > >different issue from the 'create partition-delete partition- > >partition still in /proc/partitions' issue which I've described > >earlier, because I can reproduce it on system with udev-128. > > Hi Petr,
Hello, > I think that it is still possible that both the resizing problem and > the "create partition-delete partition-partition still in > /proc/partitions" might be due to the same root problem. The change > to udev-138 might simply have increased the frequency of occurrence > of the problem. IMO the root problem in both cases is that while kernel is instructed to modify its internal partition table, something is touching the device and thus the ioctl fails. What might differ is what this thing is and how it is triggered. In my case, I still believe it's hal as shown by lsof. > With the resizing problem when the "failure to inform kernel of > partition changes" problem occurs, the entry in /proc/partitions is > not updated. Hence it will contain the old size for the partition > instead of the new size. This is similar to the problem you found > with /proc/partitions not being updated (entries not being created or > deleted). Exactly. > If I understand udev properly, it is responsible for creating, > deleting, and updating devices in the /dev directory Yes. > and hence > /proc/partitions too. AFAIK no - at least for regular disks, it is not udev, but the kernel itself who updates entries in /proc/partitions (triggered by BLKPG* and BLKRRPART ioctls). > Perhaps you could try your test with the potential patch I posted to > see if it helps the situation? I do my tests with parted-1.8.8 [*], which still uses BLKPG* ioctls to inform the kernel and thus the different codepath than your patch modifies. Anyway, I'm thinking about similar patch that would retry the BLKPG_DEL_PARTITION several times, eventually with a short sleep before the last try (fixing race condition with sleeping is not a most robust solution, but I can't think of anything better now). [*] I know this version is 'a bit' older, but it is my primary concern now (distribution stuff :/ ) > My testing of the patch has been running for over 3 days and over > 43,000 iterations. So far no problems with "failure to inform kernel > of partition changes" have occurred. This is the largest number of > iterations I have been able to run with my test prior to encountering > a problem with the kernel re-reading the partition table. I think your solution should work in most cases, however, the proper fix would IMHO be to somehow gain exclusive access to the device to prevent anything else from opening it. I don't know if it's doable, though. > I expect it will take at least another 3 or 4 days for the test to > reach 99,999 iterations. I will report back to this mailing list > with the results of this test. Regards, Petr -- Petr Uzel, openSUSE Boosters Team
pgp8qLsfIA8sD.pgp
Description: PGP signature
_______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
