inotify und proc/mounts

Hallo.

Ich habe eine frage zu inotify und proc/mounts on hoffe das mir jemand weiter helfen kanns weil dazu relativ wenig info gefunden habe..
Folgendes vorhaben:
ich watche einen frei definierbaren folder per inotify_add_watch.
Triggert der watch mach ich was mit dem folder - was ist nicht weiter wichtig, wichtig ist nur das wenn das ein USB/Externe HDD ist will ich eine UUID haben, damit ich sie später wieder erkenne, auch wenn in nen anderern path gemounted.
Die UUID hohle ich mir indem ich erst den passenden mountpoint aus proc/mounts suche, dann stat64 mache und dann in /run/udev/data/xx:yy die serial lese.

Das ganze funktioniert perfekt bei normalen foldern. Wird allerdings ein folder gewatched der auch mountpoints enthält wird das ganze etwas kompliertiert..

Folgendes passiert:
inotify triggert, ich finde den neuen ordner.
Nun will ich rausfinden ob das ein usb mount it. Als erstes guck ich in proc/mounts nach ob das ein mount ist und falls ja, jo der mountpoint liegt.

Überschung 1: cat /proc/mounts nachdem der inotify getriggert hat enthält das device nicht.

Ok.. womöglich udev nocht nicht mitn updaten nachgekommen (???? oO), also stat64 und über die device id in /run/udev/data nachgucken.
Überschung 1: st_redv ist 0.

Und jetzt komme ich langsam ins zweifeln ob inotify_add_watch wirklich so funktioniert wie ich mir das vorstelle.. wann genau triggert das? Irgendwie sieht es so aus als wüsste udev noch überhaupt nichts von dem device zum zeitpunkt wo das signal kommt.
Ich bekomme das signal von inotify zu nem zeitpunkt wo weder proc/mounts up to date ist, noch stat64 in der lage ist mir eine device id zu liefern.

Wie löse ich das?
Wenn ich nach dem inotify signal einfach dumm 5s warte vor ich proc/mounts lese / stat64 aufrufe klappt es, aber das kann doch nicht die lösung sein..^^ was ist wenn das mal 5,001s dauert bis der mountpoint in proc/mounts steht? oO

pferdefreund

und wenn man in einer (begrenzten) Schleife nachschaut, obs da ist ?
Wenns länger wie ne Minute dauert - Fehlermeldung ausgeben oder so ?
Eventuell hängt das mit den commit-Takt des Kernes zusammen - keine Ahung - aber so Geschichten haben wir sogar mit geshareten Platten auf 2 Z/OS-Systemen - da wird auch einfach in die Abläufe ein wait eingebaut, damit die Daten konsistent sind.

Thx Glaub hab ne Lösung.
Der grund für das verhalten scheint wohl wirklich das proc/mounts update zu sein, das wohl nicht direkt vom kernel gemacht wird sondern von nem daemon (jedenfalls hier auf ubuntu), passier also zeitversetzt.
Hab das jetzt so gelöst das ich ein stat64 auf dem neuen folder und seinen partent folder mache. Habe die unterschiedliche st_dev weiß ich schon mal dass das ein mount von irgendwo anders ist - sind die st_dev gleich gleich, gehts sofort weiter im "normal folder" modus. Ansonsten gibts ein return ErrPending - was dann gar nichts weiter macht, sondern sich darauf verlässt das eh gleich der watch auf proc/mounts mit dem neuen mountpoint drinnen triggert, über den ich dann an den die device id / serial komme.