SymLinks mit Groesse 0 Bytes

[michaelfuchs]

HI!

habe die Konfiguration mit "make menuconfig" ganz NEU gemacht.
Von der alten .config wurde nichts übernommen!

Habe im Linux ein "apt-get update && apt_get upgrade" gemacht.

 

[er13]

Das einzig gemeinsame bei beiden Build-Umgebungen ist die von mir gewählte Configuration

Und wie sieht es mit der Hardware aus? Ist es derselbe Rechner? Hat er zufälligerweise einen Quad-Core-Prozessor? Könntest Du bitte testen, ob der angehängte Patch das Problem behebt? (habe nur getestet, dass sich das Image erstellen lässt, da weder eine 7270 noch einen Quad-Core-Proc besitze). Vor dem Bauen make squashfs3-distclean einmal ausführen...

 

[Silent-Tears]

Sollte eigentlich in ner VM laufen. Mit 1 oder 2 Prozessoren...

 

[RalfFriedl]

Wieso sollte das besser werden, wenn man die Sperre während des Aufrufs von queue_put freigibt?

 

[er13]

die Sperre während des Aufrufs von queue_put freigibt?

eigentlich behält (man beachte die Reihenfolge der entfernten Zeilen und den Kontext). Habe nur das hier gelesen, Vermutungen angestellt und diese Änderung backportiert.

 

[RalfFriedl]

Vielleicht. Wobei ich auf einem Doppelkern bisher keine Schwierigkeiten hatte. Und Meldungen wie "Failed to read file" passen nicht so recht dazu.

@michaelfuchs
Kannst Du mal feststellen, ob zum einen bei aufeinander folgenden Aufrufen von mksquashfs die Fehler die gleichen sind, und einen Aufruf mit strace laufen lassen?

 

[er13]

Und Meldungen wie "Failed to read file" passen nicht so recht dazu.

Die Fehlermeldung ist etwas irritierend, denn sie kommt aus der Funktion write_file, in der nicht mehr von der Platte sondern aus der internen Queue von Datei-Fragmenten gelesen wird. Daher kann zu frühes Freigeben der Sperre beim Befüllen der Queue durchaus zu diesem "Lese"-Fehler führen. Für den Fall, dass es doch am eigentlichen Lesen liegt, habe ich noch diese Änderugen rückportiert: 1.87, 1.90, 1.91, 1.95. Patch anbei...

@michaelfuchs
Kannst Du mal feststellen, ob zum einen bei aufeinander folgenden Aufrufen von mksquashfs die Fehler die gleichen sind, und einen Aufruf mit strace laufen lassen?

@michaelfuchs
würde mich auch interessieren

 

[michaelfuchs]

Hallo Leute,

die letzten paar Antworten/Beiträge lassen es für mich aussehen als ob da irgend ein Timing Problem besteht.
Mein PC ist schon etwas älter, also nicht so sehr Schnell. Auch hat er nur eine CPU.

In der .config gibt es doch die Stelle "Number of jobs to run....".
hab da mal eine 1 reingemacht, und nach einem "svn up" ein "make menuconfig" und ein "make" gemacht.

Und das erzeugte image hat die Fehler nicht mehr.
Habe den build 3 mal wiederholt und auch (spasseshalber) mit der Labor-Vorschau-85 geteste. waren alle ok!

Ist das jetzt Zufall, oder?

@geändert@:
habe noch etliche Firmware Builds mit geänderter .config durch geführt. Leider tritt der Fehler sporadisch wieder auf. Nicht mehr soviele Dateien wie vorher, aber die libresolv z.B. ist immer dabei. Also doch nur Zufall!

 

[RalfFriedl]

Für den Fall, dass es doch am eigentlichen Lesen liegt, habe ich noch diese Änderugen rückportiert:

Warum rückportiert? Gibt es denn einen Grund, warum wir nicht die aktuelle Version verwenden?

@michaelfuchs
Diese Einstellung "Number of jobs" sollte nur für Aufrufe von make relevant sein, nicht für mksquashfs. Aber Zufall oder nicht, Du kannst die Änderung ja rückgängig machen und schauen, was passiert. Ich habe bei "Number of jobs" übrigens den Wert 16 und noch nie dieses Problem mit mksquashfs gehabt.

 

[er13]

Warum rückportiert? Gibt es denn einen Grund, warum wir nicht die aktuelle Version verwenden?

meines Wissens muss mksquashfs zu der im Kernel enthaltenen Version von squashfs passen. In freetz wird Version 2.2r2 für den 2.6.13- und 3.4 für den 2.6.19-Kernel verwendet.

@michaelfuchs: könntest Du bitte versuchen, das Problem erneut zu reproduzieren, in diesem Thread hatten wir was ähnliches, sodass ich das Problem gerne lösen würde.

 

[michaelfuchs]

meines Wissens muss mksquashfs zu der im Kernel enthaltenen Version von squashfs passen. In freetz wird Version 2.2r2 für den 2.6.13- und 3.4 für den 2.6.19-Kernel verwendet.

@michaelfuchs: könntest Du bitte versuchen, das Problem erneut zu reproduzieren, in diesem Thread hatten wir was ähnliches, sodass ich das Problem gerne lösen würde.

Hi,

habe zu Testzwecken noch etliche Male ein Build Image gemacht. Der Fehler tritt jetzt sporadisch auf. Es gibt images da habe ich keinen Fehler, aber andere images haben welche und ist immer ist "libresolv" mit dabei.
Ist halt eine Zeitfrage. Werde jetzt mal anfangen ein Image mit nur der Freetz-Basis zu bauen und dann mehr dazu nehmen bis ich die Konfiguration erreicht habe, die ich immer benutze. Mal sehen was da passiert.

 

[er13]

Es gibt images da habe ich keinen Fehler, aber andere images haben welche und ist immer ist "libresolv" mit dabei.

ok eine Datei (libresolv) ist zufälligerweise immer mitdabei, aber ansonsten ist die Menge der Dateien, bei denen der Fehler auftritt, nicht immer dieselbe, habe ich Dich richtig verstanden?

Hast Du jetzt mit meinen beiden Patches oben oder ohne getestet? Wenn ohne könntest Du sie bitte anwenden und erneut ein Stress-Test machen ohne irgendwelche Änderungen an der Konfiguration vorzunehmen. Danke!

 

[michaelfuchs]

Hallo er13,

Du hast recht.
Es sind nicht immer diegleichen Dateien.
Mal mehr, mal weniger.
Aber "libresolv" war immer dabei.

Deine patches habe ich noch nicht eingespielt.

20100528 16:00
============
Habe mein CoLinux-Buldsystem, die VMWare Lösung war zu langsam, mit "make distclean" gesäubert, dann habe ich nach einem "svn up" nochmal angefangen successive von einem Mini-Freetz bis zu meiner persönlichen Maximal-Lösung alles in mein Image einzubauen. Begonnen habe ich vor 2 Tagen.
Habe etwa 5 Images gemacht, alle ohne den "Symlink 0Byte" Fehler.

Es sieht so aus als ob alles wieder ok wäre.

Das hier alles, incl. der Freetz-Basis, ist im Image:
* AVM-Firewall
* Callmonitor
* cifsmount
* Downloader
* Inetd
* lighttpd (Internet: http://emeli.homelinux.net:8008)
* OpenVPN
* PHPXmail
* Privoxy
* Samba
* Syslogd
* Tor Onion Router
* Transmission
* Virtual IP
* vnstat
* XMail

Firmware Version: 54.04.80freetz-devel-4943M
.