Hallo zusammen, ich versuche gerade herauszufinden, welche Teile des Dateisystems beim NGW100 auf das RAM gemountet sind. Weiß jemand, wo das definiert wird? Passiert das zur Laufzeit in einem der Startskrips in /etc/init.d oder muss ich es irgendwo in der Buildroot (Sourcecode) nachschauen? Hintergrund ist es, dass mehrere Programme auf einfache Weise Daten untereinander austauschen sollen. Ich möchte das über Dateien machen. Nur dürfen diese natürlich nicht ins Flash gespeichert werden, sonst wäre es sehr schnell defekt. Und es stellt sich auch noch eine weitere Frage, die ich bisher nicht klären konnte. Angenommen ich habe eine ramdisk gemountet auf /ramdisk. Dort lege ich jetzt eine Datei an. Wird dabei irgendetwas ins Flash geschrieben? Ein Dateisystemeintrag beispielsweise, denn das Rootfilesystem befindet sich ja im Flash. Ich möchte, dass das Flash im Betrieb nach Möglichkeit überhaupt nicht geschrieben wird, denn das Zielsystem soll eine Lebenserwartung von 40 Jahren haben und da kann ich es nicht brauchen, dass sich das Flash totschreibt. Ich habe auch schon die ganzen automatischen logs abgeschaltet, obwohl ich mir bei diesen nicht ganz sicher bin, ob sie überhaupt auf das Flash geschrieben werden. Gibt es irgendeine globale Einstellung, die das Schreiben auf das Flash ganz verbietet? Wäre schön, wenn mir jemand helfen könnte. Viele Grüße, Peter
ich würds über avr32@atmel.com probieren, deren Hotline ist echt gut in solchen Fragen. Wäre nett wenn Du die Lösung auch hier reinpostest.
hi! Was sagt denn mount auf der Console? Und was sagt cat /proc/mounts ? Das rootfs könnte man ggf ro mounten und da wo es nötig ist eine ramdisk einbauen. Da gibt es sehr viele möglichkeiten.... Und einiges davon ist vermutlich schon umgesetzt. >>Und es stellt sich auch noch eine weitere Frage, die ich bisher nicht >>klären konnte. Angenommen ich habe eine ramdisk gemountet auf /ramdisk. >>Dort lege ich jetzt eine Datei an. Wird dabei irgendetwas ins Flash >>geschrieben? Ein Dateisystemeintrag beispielsweise, denn das >>Rootfilesystem befindet sich ja im Flash. Wieso sollte da was in Flash wandern? Im VFS sind an verschiedenen stellen verschiedene Dateisystem eingebunden. z.b. ein tmpfs unter /ramdisk. Alle Zugriffe unterhalb von /ramdisk landen im RAM. Dein Rootfs / hat damit nix zu tun. Dort ist das nur ein simples Verzeichniss. Linux speichert allerdings wann der letzte Zugriff auf eine Datei erfolgte. Das läst sich per mountoption noatime abstellen. Schön das jemand den Pinguin für derart langlebige Sachen auserwählt hat :-) PS: wegen den 40 Jahren: http://en.wikipedia.org/wiki/Year_2038_problem
Hallo Tim, das sieht so aus: ~ # mount rootfs on / type rootfs (rw) /dev/root on / type jffs2 (rw) proc on /proc type proc (rw) sys on /sys type sysfs (rw) dev on /dev type tmpfs (rw) pts on /dev/pts type devpts (rw) config on /config type configfs (rw) tmp on /tmp type tmpfs (rw) run on /var/run type tmpfs (rw) samba on /var/lib/samba type tmpfs (rw) log on /var/log type tmpfs (rw) /dev/mmcblk0p1 on /media/mmcblk0p1 type vfat (rw,sync,fmask=0000,dmask=0000,codepage=cp850,iocharset=iso8859-1) /dev/mtdblock3 on /usr type jffs2 (rw) ~ # und so: ~ # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / jffs2 rw 0 0 proc /proc proc rw 0 0 sys /sys sysfs rw 0 0 dev /dev tmpfs rw 0 0 pts /dev/pts devpts rw 0 0 config /config configfs rw 0 0 tmp /tmp tmpfs rw 0 0 run /var/run tmpfs rw 0 0 samba /var/lib/samba tmpfs rw 0 0 log /var/log tmpfs rw 0 0 /dev/mmcblk0p1 /media/mmcblk0p1 vfat rw,sync,fmask=0000,dmask=0000,codepage=cp850,iocharset=iso8859-1 0 0 /dev/mtdblock3 /usr jffs2 rw 0 0 ~ # Ich habe schon rausgefunden, dass Dateien, die in Ordnern mit filesystemtype tmpfs zumindest nach einem reboot weg sind, ich war mir nur nicht sicher, ob das bedeutet, dass sie nicht im Flash sind. Grüße, Peter
du könntest auch einfach teile oder alles ro (readonly) mounten.. wenn das für deine Anwendung passt...
Hallo Peter, eins vorweg: Ich arbeite zwar seit längerem mit Linux, kenne aber den Buildroot vom NGW100 nicht. Vielleicht können dir aber trotzdem ein parr Erklärungen helfen: >~ # mount >rootfs on / type rootfs (rw) >/dev/root on / type jffs2 (rw) / ist in einem Journalling Flash File System v2 abgelegt. Das ist Robust, und in deinem Fall beschreibbar (rw). >proc on /proc type proc (rw) >sys on /sys type sysfs (rw) Das sind virtuelle Dateisysteme deren Inhalt erst beim Zugriff aus den Datenstrukturen der Kernel erzeugt wird. Also kein Flash, Theoretisch nicht mal RAM. >dev on /dev type tmpfs (rw) Eine Ramdisk mit den Device Nodes. >pts on /dev/pts type devpts (rw) >config on /config type configfs (rw) Beides virtuelle Dateisysteme. >tmp on /tmp type tmpfs (rw) Noch eine Ramdisk, hier für temporäre Files Da sollten deine, oben beschrieben, Files für den Datenaustausch zwischen den Programmen hin. >run on /var/run type tmpfs (rw) Hier liegen die PID Files in einer Ramdisk. >samba on /var/lib/samba type tmpfs (rw) Hier liegen die Datenbanken von Samba in einer Ramdisk. Währe zu klären ob die automatisch irgendwo gesichert werden... >log on /var/log type tmpfs (rw) Die Logfiles sind auch in einer Ramdisk. >/dev/mmcblk0p1 on /media/mmcblk0p1 type vfat >(rw,sync,fmask=0000,dmask=0000,codepage=cp850,iocharset=iso8859-1) Sieht aus wie ein SD Karte mit Fat die unter /media/mmcblk0p1 hängt. Durch die sync option ist das zwar nicht schnell, aber relativ stromausfall sicher. /dev/mtdblock3 on /usr type jffs2 (rw) Sämtliche Userprogramme liegen in einer extra Partition im Flash und sind auch schreibbar. >und so: >~ # cat /proc/mounts Sagt das gleiche, also wird die Busybox verwendet :-) Es wurden bereits die stellen in denen immer was los in Ramdisks gepackt. /, /usr und damit vermutlich auch /etc (mit den Config files) liegen jedoch im Flash und können jederzeit verändert werden. Das macht Veränderungen am System sehr einfach, könnte jedoch bei dir zu Problemen führen. /usr sollte sich problemlos auf Readonly betrieb umstellen lassen da dort nur Programme, die nicht zum Booten des Systems benötigt werden, drin sein dürfen. Mit mount -o remount,ro /usr läst sich das machen. / wird komplizierter, da beim booten und auch im späteren Betrieb sich noch Dateien unter /etc und /var ändern können. Übliche verdächtige sind z.b. DHCP Client/Server, cron, lockfiles unter /var/lock, Mailserver, ... Da hilft nur eine Analyse des Systems und der verwendeten Programme. Ist aber machbar. Sinnvollerweise fängt man damit an, erstmal alles wegzulassen / abzuschalten was man nicht brauch (samba z.b.). Hängt natürlich auch sehr stark von deinem Anwendungsfall ab. >Ich habe schon rausgefunden, dass Dateien, die in Ordnern mit >filesystemtype tmpfs zumindest nach einem reboot weg sind, ich war mir >nur nicht sicher, ob das bedeutet, dass sie nicht im Flash sind. Bei tmpfs landet nichts im Flash, nur im RAM. Der Speicherplatz wird dynamisch vom freien RAM weggenommen, leere Ramdisks kosten also fast Nix. (Auf normalen PCs ist deine vermutung richtig, da werden die ramdisks nicht verwendt, und beim booten jediglich die alten Inhalt (teilweise) entsorgt.) Grüße
Danke Tim für die ausführliche Antwort. Das mit dem readonly mounten vom
Rootfilesystem macht noch etwas Ärger, ich muss wohl wirklich dafür
sorgen, dass kein Programm mehr irgendetwas ändert. Auch ist mir noch
nicht ganz klar, was die noatime option macht. Ich habe das so
verstanden, dass jede Datei ein Datum des letzten Zugriffs hat. Das wird
im Dateisystem gespeichert. Mit der option noatime soll das Speichern
des Änderungsdatums verhindert werden.
Dazu habe ich jetzt zwei Fragen.
Zunächst, wo denn diese Timestamp überhaupt gespeichert wird. Wenn ich
eine Datei innerhalb einer ramdisk ändere, wird dieser eine neue
Timestamp zugewiesen, aber wo wird die Timestamp gespeichert, im Ram
oder im Rootfilesystem?
Dann gibt es bei mir noch das Problem, dass eben diese Option nicht
funktioniert, ich kann sie in /etc/fstab eintragen, sie wird nach einem
Neustart auch mit dem Befehl mount angezeigt, wenn ich aber eine Datei
in der entsprechenden Ramdisk anlege, sehe ich mit ls immer noch ein
korrektes Datum. Habe ich etwas falsch verstanden, oder ist das ein
Fehler?
Dann gibts diese Option auch noch für Ordner, das hab ich noch nicht
ausprobiert. Wenn das Flashfilesystem readonly ist, wären doch diese
Einstellungen ohnehin egal, oder? Es genügt aber beim ngw100 nicht, nur
in der fstab die option ro zu setzen, das nützt nichts, ich muss es
wahrscheinlich schon beim bootloader als Option angeben, hab das aber
noch nicht ausprobiert.
Was passiert eigentlich, wenn das System Dateien schreiben will, wenn
das Dateisystem readonly ist? Gibt es eine Fehlermeldung und wenn ja,
wohin? Auf stderr? Als Broadcast auf alle Terminals? Oder wird das ohne
weiteres still ignoriert?
Weiß eigentlich jemand, was winbindd macht? Wenn ich von Zeit zu Zeit
top aufrufe, sehe ich, dass es immer mehr Prozesse gibt, die winbindd
heißen.
Ich möchte keine Prozesse starten, die ich nicht benötige und habe dazu
auch schon einige aus der init.d erfolgreich ausgebaut.
top sieht im Moment so aus:
Mem: 12720K used, 18220K free, 0K shrd, 24K buff, 6096K cached
Load average: 0.00 0.00 0.00
PID USER STATUS RSS PPID %CPU %MEM COMMAND
3594 root R 312 3593 0.6 1.0 top
3592 root S 384 312 0.1 1.2 dropbear*
333 root S 1428 1 0.0 4.6 smbd
338 root S 928 333 0.0 2.9 smbd
328 root S 912 1 0.0 2.9 nmbd
339 root S 876 1 0.0 2.8 winbindd
343 root S 820 339 0.0 2.6 winbindd
299 root S 428 1 0.0 1.3 ntpd*
3593 root S 372 3592 0.0 1.1 ash*
389 root S 364 1 0.0 1.1 sh*
1 root S 308 0 0.0 0.9 init*
283 root S 252 1 0.0 0.8 dnsmasq*
312 root S 232 1 0.0 0.7 dropbear
319 root S 220 1 0.0 0.7 inetd*
165 root S 204 1 0.0 0.6 syslogd
176 root S 184 1 0.0 0.5 klogd
348 root S 124 1 0.0 0.3 httpd*
248 root S 120 1 0.0 0.3 udhcpc*
228 root SWN 0 1 0.0 0.0 jffs2_gcd_mtd3*
95 root SWN 0 1 0.0 0.0 jffs2_gcd_mtd1*
5 root SW< 0 1 0.0 0.0 khelper
In Frage für eine Rauswurf kommen
syslogd
smbd (warum ist das mehrfach am laufen?)
winbindd (weiß nicht, was das macht)
dropbear (woher kommt Nummer 2 davon?)
klogd (was ist das?)
Alle Prozesse, die ich kenne und die unbedingt laufen müssen, hab ich
mit einem * markiert, bei den anderen bin ich mir nicht sicher was sie
tun, bzw. ob sie benötigt werden, ich werde einfach mal ausprobieren,
was passiert, wenn ich sie deaktiviere.
Grüße,
Peter
hi! Zu deinem noatime Problem: Es gibt 3 Zeitstempel: ctime(Create) Da wurde die Datei erzeugt. mtime(Modify) Hier wurde sie verändert. atime(Access) Da hat jemand zuletzt die Datei gelesen. noatime bewirkt das die Access Time nicht mehr geändert wird. Habe ich eben hier überprüft, funktioniert wie erwartet. Aber ls zeigt dir normalerweise die mtime an. --time= kann das ändern, sofern die Busybox das unterstützt.... >Wenn das Flashfilesystem readonly ist, wären doch diese >Einstellungen ohnehin egal, oder? Ja, Aber dann sind keine Änderungen mehr möglich. Wenn das in deinem Anwendungsfall geht, ok. >...aber wo wird die Timestamp gespeichert, im Ram >oder im Rootfilesystem? Alle Zugriffe unter Linux landen erstmal beim VFS. Das ermittelt dann aufgrund der gemounteten Dateisysteme welches für den Zugriff zuständig ist. Und dieses kümmert sich dann um die Daten, aber auch um die Verwaltungsinformationen. Ergo bei tmpfs im RAM. >Es genügt aber beim ngw100 nicht, nur >in der fstab die option ro zu setzen, das nützt nichts, ich muss es >wahrscheinlich schon beim bootloader als Option angeben, hab das aber >noch nicht ausprobiert. Ich tippe mal, das in der Kernel Commandline vom Bootloader ein rw übergeben wurde. cat /proc/cmdline weiss das. >Was passiert eigentlich, wenn das System Dateien schreiben will, wenn >das Dateisystem readonly ist? Gibt es eine Fehlermeldung und wenn ja, >wohin? Auf stderr? Als Broadcast auf alle Terminals? Oder wird das ohne >weiteres still ignoriert? Die Kernel selbst meckert nur wenn die Hardware nicht geht. Ein Prozess welcher schreiben wollte, bekommt von der Kernel die Rückmeldung das das nicht geht. Je nach Qualität der Fehlerbehandlung kann das Gut oder Böse ausgehen. Von startet nicht bis funktioniert perfekt ist alles drin. Da hilft source lesen oder probieren. Wenn es ein Daemon ist sollte er eine entsprechende Meldung beim syslogd abliefern. Broadcasts macht nur die Kernel wenn es kritisch ist. In /proc/sys/kernel/printk kann man festlegen was kritisch ist (bis zum neustart). Tipp: Es gibt Symbolische Links. Die funktionieren auch über Dateisystem Grenzen hinweg. Wenn ein solcher Link in einem Read only Filesystem liegt, aber auf eine schreibbare Datei (z.b. im tmpfs) verweist, kann man trotz Read only die Datei verändern, sie liegt physikalisch ja schlieslich im tmpfs. Sofern ein Prozess nicht extra nachfragt, wird er davon Nix merken. Dann muss man beim booten aber die Datei ins tmpfs kopieren und einen neustart überleben die änderungen an der Datei auch nicht. >Weiß eigentlich jemand, was winbindd macht? Wenn ich von Zeit zu Zeit >top aufrufe, sehe ich, dass es immer mehr Prozesse gibt, die winbindd >heißen. Stichwort: Samba also "Netzwerkumgebung" Er Sorgt dafür, das User die im SMB Netz exestieren, auch in der Linux Benutzerverwaltung auftauchen. Sofern du den Samba nicht in eine NT-Domain eingliederst brauchst du den nicht. >In Frage für eine Rauswurf kommen >syslogd Schlechte Idee. Der nimmt log einträge entgegen und sortiert sie in die Logfiles unter /var/log/ ein. (Sofern die Busybox Variante das auch tut. Wenn ich mich recht erinnere ist bei der Bussybox einer dabei der nicht in Dateien sondern nur in einen Ringpuffer schreibt. Müsste man klären.) >smbd Möchtest du das die Kiste im Windows Netzwerk auftaucht und Verzeichnisse freigeben? Nein? Gut. Weg damit. >(warum ist das mehrfach am laufen?) Normal, Für jeden verbunden User einen + welche zu Verwaltung,... >dropbear (woher kommt Nummer 2 davon?) Das ist der ssh Server. Wie bist du eingelogt? Per ssh mit putty? Wenn dir ein Serielles Kabel reicht kannst du ihn entsorgen. 2 Stück weil der 1. (pid 312) vom init gestartet wurde und auf neue Verbindungen wartet. Nummer 2 ist der mit dem putty(?) gerade spricht und hat die ash (pid 3593) für dich angeworfen. (Und die wiederum top :-) >klogd (was ist das?) Kernel Log Daemon. Ein Zuträger von syslogd. Er sammelt die Meldungen der Kernel ein und schickt sie an syslogd. Würde ich lassen. Ich hätte auch noch welche: nmbd: Gehört zu Samba und sorgt für die Windows Namensauflösung. Wenn kein Samba dann auch kein nmbd. inetd: Sofern er nicht den httpd startet, währe zu klären was er sonst macht. /etc/inetd.conf währe interresant. udhcpc: schreibt warscheinlich irgendwo in /var ntpd: schreibt ggf auch irgendwo in /var Der dnsmasq steht auch zu diskusion. Es sei denn, das soll ein "router" werden. Ok, viel Text, aber Vielleicht hilft es ja ;-)
Such mal bei google nach "mmap shared memory" insbesondere die MAP_SHARED und MAP_ANONYMOUS Modi bzw. das mappen von /dev/null können evtl. deine Probleme eleganter lösen.
Vielen Dank, das hilft mir wirklich weiter. Nachdem ich die beiden log-Dienste syslogd und klogd abgeschaltet habe, ist jetzt auch mehr Speicher frei, denn die Logfiles wurden in /var/log, also im Ram abgelegt. Die logs interessieren mich eigentlich nicht, also habe ich beschlossen, das logging nur einzuschalten, wenn ich gerade etwas neues ausprobiert habe und verlasse mich ansonsten darauf, dass alles in Ordnung ist. Das System soll später schließlich jahrelang laufen und da schaut auch keiner die logs an, abgesehen davon, dass der Inhalt auf diesem kleinen Rechner nicht besonders interessant ist. Samba benötige ich nicht, also habe ich alle Dienste davon deaktiviert (samba start in init.d abgeschaltet). cat /proc/cmdline liefert: console=ttyS0 root=/dev/mtdblock1 rootfstype=jffs2 Also keine ro Option. Ich werde das mit ro demnächst ausprobieren, ich muss mich dafür aber erst in den Bootloader einarbeiten, es wird U-Boot verwendet. Wenn grundlegende Änderungen am Rootfilesystem zu machen sind, muss man das eben temporär rückgängig machen. Das wird aber nicht oft sein, alle meine Programme und Websites kommen auf die SD-Karte. Das ganze ist ein Forschungsprojekt und wird dann ein Gebäudeleitrechner, der ein momentan laufendes Linuxsystem mit PC (Pentium III) ablösen soll. Im wesentlichen macht der Rechner die außenhelligkeitsabhängige Beleuchtungssteuerung und Ela in einem relativ großen Gebäude. Das momentane System soll abgelöst werden, weil der PC recht viel Wartungsarbeit benötigt (Festplatten, Lüfter, immer wieder reinigen...) und der Energieverbrauch gesenkt werden soll. Das alles läuft mittlerweile schon seit einigen Jahren und es ist jetzt so viel daran angebunden, dass die Zuverlässigkeit wesentlich ist. Deswegen wird es wohl einfach zwei davon geben (mit identischer Software), die im Bedarfsfall schnell gegeneinander getauscht werden können. Die Anbindung an die Gebäudetechnik habe ich mit EIB und Powerline Modems realisiert, die Ela bekommt ein analoges Audiosignal, das alles soll dann das ngw100 machen. Ich werde dafür noch weitere serielle Schnittstellen aktivieren und ausprobieren, wie man Audioausgaben von wavfiles und mp3s machen kann. Außerdem werde ich die Webseiten dynamisch per cgi angebunder Programme erstellen, das wird auch noch ein spannendes Kapitel. Bis dahin bedanke ich mich für die ausführliche Hilfe, ich denke, meine Probleme mit dem Dateisystem und unbekannten laufenden Prozessen sind weitgehend als gelöst anzusehen. Viele Grüße, Peter
> Lebenserwartung von 40 Jahren
Vollkommen unrealistisch.
In 40 Jahren ist der Flash-Speicher nur noch Brösel, das SDRAM hat so
hohe Leckströme dass Du darauf Eier grillen kannst, und die Strukturen
im der CPU sind vollständig zusammenlegiert.
Dann habe ich zumindest gezeigt, dass es nicht geht, aber besser als ein PC ist es allemal. Abgesehen davon sind die angegebenen Lebenserwartungen, z.B. Dataretention des Flash (20 Jahre) bezogen auf den worst case, d.h. absolut maximum ratings. Auf dem Board bleibt aber wirklich alles kalt und ich bin zuversichtlich, dass die 40 Jahre erreicht werden können. Ich kenne mehrere über 30 Jahre alte Mikrocontrollerschaltungen aus der Automatisierungstechnik, die seit der Inbetriebnahme bis heute noch immer fehlerfrei laufen, warum sollte das mit den neuen Prozessoren nicht auch möglich sein? Peter
> warum sollte das mit den neuen Prozessoren nicht auch möglich sein?
Deutlich kleinere Strukturen, Flash anstatt ROM/PROM, dynamisches RAM
anstatt statisches RAM etc.
Dieses Problem hat wohl jedes halbwegs aktuelle Automatisierungssystem, ich bin mir dessen auch bewusst und die 40 Jahre sind ein Wunsch, den ich gerne hätte, wenn es nicht so lang lebt, dann eben nicht. Vor allem möchte ich aber vermeiden, dass ein systematischer Fehler, wie z.B. das zyklische Beschreiben des Flash zu einem verfrühten Ausfall führt, deswegen dieser Thread. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.