fseventsd (auf client) -> ständige Aktualisierung von bestimmten Dateien

[tau]

Hallo zusammen,
ich habe hier ein Denksportaufgabe, die ich nicht gelöst bekomme..


Folgendes Szenario
Server: Mac Mini mit OSX Server 10.6.6 sorgt für Dateifreigabe via AFP, ganz klassisch, keine weiteren Dienste.
Client: Mac Pro mit 10.6.6 greift auf diese Daten zu..
Netzwerk: SOHO-Router, Gigabit, nichts Spezielles.


Jetzt kommt es hin und wieder vor, daß mir auf dem Client der Finder träge wird und seltsamer Netzwerktraffic auftritt.

Um also herauszufinden, welcher Prozeß was gerade wo schreibt, schmeiße ich dann dieses wunderbare grafische Tool fseventer an,
welches mir zeigt, daß der Prozeß fseventsd (welch Zusammenhang ) permanent im 1/2 Sekundentakt irgendeine einzelne Datei auf dem gemounteten Serververzeichnis liest und schreibt. Immer die selbe.
Und zwar so lange, bis ich fseventsd in der Aktivitätsanzeige abschieße.

Danach ist wieder alles ruhig, bis dann irgendwann (am nächsten Tag oder so - jedenfalls unregelmäßig) das selbe Phänomen mit irgendeiner anderen Datei wieder auftritt.

Ein Zusammenhang mit einer Datei, die ich gerade bearbeite, besteht nicht.
In den Logfiles finde ich auch nichts.

Was hat ein Systemprozess wie fseventsd mit so einer wahllosen Datei zu schaffen und warum?

 

[DrunkenFreak]

Versuch fseventsd doch mal mit einem trace zum Singen zu bringen.

 

[tau]

Ich steh' gerade auf dem Schlauch - was genau meinst Du mit trace?

 

[DrunkenFreak]

Verschiebe die Datei fseventsd nach fseventsd.s und erstelle anstattdessen ein Skript, dass fseventsd.s mit dtrace zusammen aufruft. Das ganze lässt du dir irgendwo hinloggen und dann kannst du überprüfen, was fseventsd in der ganzen Zeit gemacht hat.

 

[tau]

Verschiebe die Datei fseventsd nach fseventsd.s und erstelle anstattdessen ein Skript, dass fseventsd.s mit dtrace zusammen aufruft. Das ganze lässt du dir irgendwo hinloggen und dann kannst du überprüfen, was fseventsd in der ganzen Zeit gemacht hat.

Hi,
Danke schonmal, allerdings überschätzt Du meine Kenntnisse. Was für ein Script genau? dtrace scheint eine ziemlich umfangreiche Toolbox zu sein - mir fällt es da schwer, durchzublicken.

Trotzdem bin ich ein bißchen weitergekommen, was das Monitoren von fseventsd betrifft - allerdings sagen mir die Ergebnisse recht wenig.

Vorneweg: Ich habe beim Suchen in Netz einen Hinweis auf diverse mit OSX schon mitgelieferte dtrace-scripts gefunden
http://hints.macworld.com/article.php?story=20071031121823710

eine Übersicht bekommt man unter man -k dtrace
und ich habe mir dtruss ausgesucht und laufen lassen: dtruss -p (PID)

Ergebnis: (foo/bar habe ich mal als Platzhalter statt des echten Dateipfades eingesetzt)

   48/0x2c9:   3108315    1419    172 lstat64("/foo/bar", 0x102D038B0, 0x100200190)         = 0 0
   48/0x2c9:   3108388     923     70 lstat64("/foo/bar", 0x102D038B0, 0x71DD99E)         = 0 0
   48/0x2c9:   3108529     970    138 lstat64("/foo/bar", 0x102D038B0, 0x71DD9A1)         = 0 0
   48/0x2c9:   3108586     471     54 lstat64("/foo/bar", 0x102D038B0, 0x71DD9A4)         = 0 0
   48/0x2c9:   3108683  496040     14 __semwait_signal(0x5803, 0x2603, 0x0)         = 0 0
   48/0x2c9:   3108865     803    169 lstat64("/foo/bar", 0x102D038B0, 0x102B00A50)         = 0 0
   48/0x2c9:   3108930     671     62 lstat64("/foo/bar", 0x102D038B0, 0x71DD9AA)         = 0 0
   48/0x2c9:   3108133  496442     13 __semwait_signal(0x5803, 0x1F03, 0x0)         = 0 0
   48/0x2c9:   3109083    1475    151 lstat64("/foo/bar", 0x102D038B0, 0x71DD9AD)         = 0 0
   48/0x2c9:   3109141     712     55 lstat64("/foo/bar", 0x102D038B0, 0x71DD9B0)         = 0 0
   48/0x2c9:   3109530     620     96 lstat64("/foo/bar", 0x102D038B0, 0x71DD9B6)         = 0 0
   48/0x2c9:   3109681    1961    148 lstat64("/foo/bar", 0x102D038B0, 0x71DD9B9)         = 0 0
   48/0x224:    222703  500719     22 read(0x4, "\0", 0x17C9C)         = 569 0
   48/0x207:    401882  488368     10 __semwait_signal(0x1F03, 0x2303, 0x1)         = -1 Err#60
   48/0x2c9:   3110321    1402    186 lstat64("/foo/bar", 0x102D038B0, 0x71DD9C5)         = 0 0
   48/0x2c9:   3110382     456     57 lstat64("/foo/bar", 0x102D038B0, 0x71DD9C8)         = 0 0
   48/0x224:    222735  499859     22 read(0x4, "\0", 0x17A63)         = 569 0
   48/0x207:    401813  489059     11 __semwait_signal(0x2603, 0x2303, 0x1)         = -1 Err#60

usw. Das läuft immer so weiter.

 

[TatzeBerlin]

Hallo,
konnte Dein Problem gelöst werden?
Jetzt habe ich das nämlich auch.

 

[xentric]

Da wirst du immer eine andere Datei drin haben (in /.fseventsd/), die permanent bei jeder Disk I/O verändert wird. Der Dateiname ist eine UUID, also eine Bezeichnung, und führt Katalog darüber, welche Datei wann verändert wurde. Das wird z.B. von Spotlight, Timemachine usw. benutzt um rauszufinden welche Datei verändert wurde. Das Ding ist somit also eigentlich nicht der Verursacher deiner Disk IO, sondern ne Folge daraus.

http://developer.apple.com/library/...ference/FSEvents_Ref/Reference/reference.html

Hier ist n anderes Dtrace Script, dass den Dateinamen angibt, nicht die Inode (Dateisystem interne Bezeichnung) oder was du da hast, welche geöffnet wurde (nicht getestet):
http://system-log.tyr.org.uk/2012/0...-from-spinning-up-unnecessarily-on-os-x-lion/

Sonst kannst du das gleiche auch mit fs_usage machen. Ich hab auch immer dtrace genommen, aber schau dir mal fs_usage an:
http://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/fs_usage.1.html

 

[TatzeBerlin]

Oh, danke für den Hilfeversuch – aber das ist mir zu hoch.
Lustig, mal zu sehen, dass der Mac in 1 Sekunden 80 Sachen macht; nur anfangen kann ich damit nichts.