Hi. So I've been struggling a bit with optimizing applications calling partprobe right after lsblk to retrieve PARTUUID of newly generated partitions using parted.
Assuming the following loop: * partprobe * lsblk * if !result: sleep + loop It feels as if every partprobe (indirectly or directly) flushes a cache/struct of information somewhere, which makes lsblk "fail" to retrieve certain information if executed too quickly in succession. A normal approach to solving this is adding a delay between partprobe and lsblk, something I wanted to avoid by putting the sleep at the very end of the loop, and instead do many quick loops until the information is available. I could also put partprobe before the loop, and continue looping until the information becomes available. But that poses an issue if the disk-operation (parted) completes after partprobe performs it's tasks. Leaving the loop in a dead state until a new partprobe is called (or that seems to be the issue at least). My question boils down to: 1. Is there a way to get an indication of when the partprobe (or kernel) has completed its task of populating the partition information? 2. Is there a way to tell partprobe/kernel to not clear the old struct before the new information is available (leaving "old information" intact until new exists, rather than wiping it and then populating) If none of the two above is possible, I would like to consider those being a feature as it would greatly help to verify when disk operations are 100% complete. I don't mind optionally hanging applications/scripts until parted is complete, as I would like to avoid continuing based on parted exit code if the exit code is not a guarantee of the process being completed in this case. Best wishes: Anton Hvornum