> Since dasdfmt does the low-level formating stuff it tries to make sure it's > the > only user of the device. But in your case it looks like sometimes it's not the > only user and it's likely that's because some worker of udev is not finished > and still has a file descriptor to this device node opened. > > So I still think it is sufficient to do: > chccwdev -e xxx ;udevadm settle ;dasdfmt xxx
Since we have ample data from multiple sources that this DOES NOT operate reliably, the original question still stands. How can we reliably block until a I/O subsystem operation is fully and reliably known to be complete? Tracing the udevadm process seems to show some /by-uuid processing that is failing due uuids being the same -- is there something in the udev device activation that somehow relies on a unique UUID? If so, that would explain why it sometimes works and sometimes doesn't (if the device you're trying to activate is on a different physical disk, you'd win here; if it's on the same physical disk, you'd lose, or at least have udev try alternative code paths to get a unique device node created and assigned. Using TDISK or VDISK for the test case would mislead, as at least tdisk could be on different physical volumes. I can send you a log from the trace if that would help you. In any case, I think Mike's question is a good one: if chccwdev needs a 'udevadm settle' to operate correctly, why isn't it doing it itself? It seems like we should be able to rely on chccwdev operations being atomic. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
