XigmaNAS

mahlzeit.

ich hatte das problem schon immer wieder auf unterschiedlichen Systemen, unterschiedlicher hardware, auch schon mit FreeNas. Aber ich steige nicht dahinter woran das liegt.

Problem:
Nach ein paar min. Musik abspielen hält firefly einfach an und die Musik ist aus.
Der nas4free läuft zwar weiter, aber das firefly muss neu gestartet werden, und dann kann man über iTunes die Datenbank neu einlesen. und wieder kann man für nen paar Minuten Musik dudeln lassen bis irgendwann dann gleich wieder stop ist.

Hier läuft komplett alles über gigabit Verkabelung, kein wlan. Als Switch ist hier ein Cisco SG-200.
Das nas4free holt sich per DHCP eine im windows 2008 R2 reservierte IP.
der Name des nas4free ist ITUNESNEU, der Samba/CIFS heisst ITUNESNEU, der firefly heisst ITUNESNEU
im DNS wird die reservierte IP auch benutzt. (ping auf ITUNESNEU ergibt die korrekte IP)

Da genau dieser nas4free Rechner bereits ne Weile tadellos lief als firefly/iTunes Server ist mir dieses Verhalten unerklärlich. bisher hab ich sowas durch Neuinstallation von nas4free gelöst, was ich nun aber nicht mehr will. Das Problem muss ja einen Grund haben.

Der ITUNESNEU ist ein mini itx board (D510M0) mit atom (D510) drauf und 4GB ram und einer 1,5TB sata pladde.
Als System läuft ein 9.3.0.2 - Nayla (Revision 1480).
es wird KEINE Auslagerungsdatei / -partition benutzt.

Braucht man weitere Infos der Konfiguration?

Für eine Lösung des Problems wäre ich echt dankbar.

kreuzberger wrote:ich hatte das problem schon immer wieder auf unterschiedlichen Systemen, unterschiedlicher hardware, auch schon mit FreeNas. Aber ich steige nicht dahinter woran das liegt.
....
Da genau dieser nas4free Rechner bereits ne Weile tadellos lief als firefly/iTunes Server ist mir dieses Verhalten unerklärlich. bisher hab ich sowas durch Neuinstallation von nas4free gelöst, was ich nun aber nicht mehr will. Das Problem muss ja einen Grund haben.
...
Als System läuft ein 9.3.0.2 - Nayla (Revision 1480).
es wird KEINE Auslagerungsdatei / -partition benutzt.

Braucht man weitere Infos der Konfiguration?

Bevor ich antworte, brauche ich von dir die Angabe darüber, was du in Services|iTunes/DAAP bei Database directory eingetragen hast. Bitte den Pfad posten.

Grüße
Princo

PS: und wenn du schon dabei bist, die Angabe darüber, was du alles bei Content eingetragen hast, wäre auch hilfreich.

hi Princo,

das Verzeichnis heisst:
/mnt/SAMSUNG01/iTunes-Datenbank

als contend / Inhalt hab ich:
/mnt/SAMSUNG01/iTunes-Musik01
/mnt/SAMSUNG01/iTunes-Musik00_meine_LPs_CDs
/mnt/SAMSUNG01/iTunes-Musik02_Favoriten
/mnt/SAMSUNG01/iTunes-Musik20_BUECHEREI
/mnt/SAMSUNG01/iTunes-Musik30_Meine_CDs

Hi kreuzberger,

kann es sein, daß du eine Full-Installation vorgenommen hast?
Das würde zumindest erklären, weshalb du den Fehler bisher nur durch eine N4F-Neuinstallation beseitigen konntest.
Es gibt schon deftige Gründe dafür, daß man niemals eine Full-Installation machen sollte.

Stell dein System auf eine Embedded-Installation (am besten auf einem USB-Stick) um, dann werden wir sehen, wie sich der Fehler dort darstellt.

Damit wir uns nicht falsch verstehen: Der Fehler wird damit noch nicht ganz weg sein, aber das Problem, welches du bisher nur mit einer Neuinstallation beseitigen konntest, wird sich dann mit einem einfachen Neustart erledigen lassen.

Mit der Embedded-Installation haben wir dann eine wesentlich besser definierte Umgebung, um dann das eigentliche Kernproblem angehen zu können.

Grüße
Princo

Hi Princo,

ja, ich hab ne füll Installation. Ich hab eigentlich nie was anderes gemacht. Bei mir laufen mehrere weitere nas4free, speziell einer wo auch das firefliy tadellos auf füll Installation läuft. ich wollte die alte Kiste nur ablösen.
firefly läuft also durchaus dauerhaft stabil mit einer füll Installation.

mir ist auch schleierhaft, was denn an einer embeddet Installation anders ist als der Punkt, dass mir jederzeit der USB stick, auf dem das system ist verrecken kann. Festplatten sind ja gemeinhin langlebiger.

"Es gibt schon deftige Gründe dafür, daß man niemals eine Full-Installation machen sollte."

Welche?

uwe

siehe faq
http://wiki.nas4free.org/doku.php?id=faq:0073

Also, bear in mind that if you use a Full install, you cannot expect support if something breaks. There is no way that anyone would be able to guess what part(s) of the system you damaged (accidentally or intentionally). You have been warned.

kreuzberger wrote:"Es gibt schon deftige Gründe dafür, daß man niemals eine Full-Installation machen sollte."

Welche?

Das, was b0ssman sagt,

und

Bei deiner Installation scheinen die Log-Dateien überzulaufen.
Bei Embedded ist das nach einem Neustart weg.
Bei der Full-Installation mußt du dich selber um das Problem kümmern, und das kannst du offensichtlich nicht, weil du das gar nicht auf dem Schirm hast.

Mit einer Full-Installation hast du nur Nachteile.

Zum Thema "Haltbarkeit" von USB-Sticks versus Festplatten:
Mir ist noch kein USB-Stick im N4F kaputt gegangen, weil davon nur gelesen wird.
Ein defekter USB-Stick wäre jedoch kein Problem, wenn man seine Konfig nach jeder Änderung sichert.
Selbst wenn man dabei schlusig sein sollte: Die Datenbereiche betrifft das nicht. Es ist sauber voneinander getrennt.
Selbst wenn mir ein USB-Stick verrecken sollte: Da stecke ich einfach einen neuen rein, installiere das System, und spiele die Config zurück. Der USB-Stick kostet nur ein paar Euro, und man hat viel weniger Streß als mit einer Full-Installation auf einer Festplatte.

Es hat wirklich seine Gründe, weshalb in der offiziellen Dokumentation von der Full-Installation ausdrücklich abgeraten wird, und es auch keinen Support dafür gibt.

Grüße
Princo

man jaaa, ich probier es aus, nu hackt nicht alle auf mir rum.

so.

hab jetzt mal das o.g. system auf nen USB Stick als embedded (Installation Auswahl 1) installiert und das Ganze vom Stick gestartet und das iTunes eingerichtet. Es läuft, und ich warte mal ob das Problem wieder auftritt.

Zur nebeninfo:
es wurde ja gesagt, dass da irgendwelche log-files Probleme machen. ich weiss nun nicht ob das problem auch wieder auftaucht, zumal das Teil am Ende egentlich dauerhaft laufen soll, bis im Jahre 7393 ggf mal der Strom abgeschaltet wird.

Hi kreuzberger,
du schriebst

kreuzberger wrote:es wurde ja gesagt, dass da irgendwelche log-files Probleme machen. ich weiss nun nicht ob das problem auch wieder auftaucht, zumal das Teil am Ende egentlich dauerhaft laufen soll, bis im Jahre 7393 ggf mal der Strom abgeschaltet wird.

Zur Erklärung:
NAS4Free ist im Prinzip ein extrem abgespeckter FreeBSD-Server, der von USB-Sticks gestartet werden kann, und dann im RAM läuft (embedded Version).
Du könntest dir aber genauso gut einen "richtigen" FreeBSD-Server installieren (der dann nicht abgespeckt ist, und dir sehr viel mehr Möglichkeiten bietet). Dann könntest du dir z.B. einen Desktop installieren, einen Mailserver betreiben, deinen Scanner und deinen Drucker einbinden, usw.

NAS4Free beschränkt sich aber ganz bewusst darauf, nur Speicherplatz im Netzwerk anzubieten.
Für genau diesen einzigen Zweck gibt es eine Web-Oberfläche, und eine zentrale Konfigurationsdatei, in der alles abgelegt ist.
Bei einem "richtigen" FreeBSD-Server müsstest du die einzelnen Konfigurationsdateien z.B. für Samba, NFS, FTP, DAAP, Mail, SSH, die Benutzerverwaltung, usw. selbst heraussuchen, pflegen, und auch sichern.

Das NAS4Free-Konzept ist darauf ausgelegt, auf eine sehr einfache Weise auch umfangreiche Systemupgrades durchführen zu können.
Das funktioniert allerdings nur, wenn man sich auch an dieses Konzept hält.
Eine Full-Instalation durchbricht dieses Konzept. Theoretisch hat man zwar mit der Full-Installation mehr Möglichkeiten, aber man hat dafür dann auch keine zentrale Benutzerobefäche und auch keine zentrale Konfigurationsdatei. Das, was man extra reinbastelt, ist in der zentralen Konfiguration einfach nicht enthalten. Darum muß man sich selber kümmern.

Dieser Fakt wird von den meisten (naiven) Nutzern der "Full-Installation" gedanklich gar nicht realisiert. In der Praxis führt das dann dazu, daß sich die "Full-Installation"-Nutzer nicht mehr trauen, ihr System upzudaten, weil ihnen dann sehr wahrscheinlich die Kiste um die Ohren fliegen wird.

Die "normalen" N4F-Nutzer betrifft das nicht. Die können ihr System jederzeit hochleveln. Die "Full-Installation"-Nutzer haben dabei immer einen Haufen Arbeit vor sich, und gucken dumm aus der Wäsche.
In der Praxis führt das dann leider dazu, daß die "Full-Installation"-Systeme dann gar nicht upgedatet werden. Damit profitieren sie auch nicht von neuen Features von NAS4Free, oder von Sicherheitsaktualisierungen.
Noch etwas: auch die Full-Installation arbeitet mit den gleichen Grundparametern wie die "Embedded-Installation", und diese sind auf eine reinen File-Service-Betrieb ausgelegt.
Wenn du mit einer Full-Installation jedoch z.B. Datenbank-Services betreiben möchtest, müsstest du diese Grundparameter ändern, damit die Datenbanken überhaupt einigermaßen performant laufen können.
Worauf ich hinaus will: Wenn man eine Full-Instalation in Betracht zieht, ist es i.d.R. zielführender, eine "richtige" FreeBSD-Server-Installation vorzunehmen.
Wenn man davor Schiß hat, sollte man gefälligst bei der "embedded"-Version bleiben.
FYI: intern wird hier durchaus darüber diskutiert, daß man die Full-Installation gar nicht mehr nach draußen gibt, weil zu viele Leute irrigerweise denken, daß die irgendwie "besser" ist.
Das ist aber nicht der Fall. Diese Installationsart ist nur für ganz spezielle Fälle nützlich, und sie bringt einen wesentlich höheren Aufwand mit sich.
Ich selbst würde sie nicht einsetzen wollen, aber ich finde es gut, daß es sie noch gibt.

Grüße
Princo

hi Princo,

danke, ich lese das gleich mal. nur mal kurz ein..

ZWISCHENBERICHT:

derzeit fülle ich das serverchen mit Daten, und es funktioniert soweit erst mal gut. aber das tat es ja anfangs auch als full intallation. ich bin gespannt.

gibt es da irgendwelche Erfahrungswerte, ob es da ne Begrenzung der Anzahl der songs / mp3-dateien gibt, ab wann das system Schwierigkeiten macht?
uwe

nochmal hi pronco,

also recht herzlichen dank, dass du dir hier solo viel mühe gibst. echt klasse!

wie du schon mitbekommen hast ersuche ich eine musikabspielkiste zu bekommen, die auf gewisse weise "unzerstörbar" ist. d.h.: nur der herr und Meister (admin) darf configs vornehmen. die normalen user, die überhaupt nur rechte haben dürfen in einen speziell vorgesehenen ordnet mukke neu reinstahlen.

deshalb auch mein threat mit dem löschen bestimmter Dateien.
am ende steht die liste dann in der Familie oder kneipe, wo dann nur noch der alte iMac zum dudeln da ist, und nur playlists erreichen kann, aber nie was ändern darf.

in solchen umgebogen ist der USB stick hinten dran ein echtes problem, denn der ist schnell weg. (such derzeit nach pfostensteckeradaper für mainboards, um den stick mit system direkt aufs board zu stecken, IM Gehäuse.

bisher dachte ich, dass die full installation auf einer festplattenpartition langlebiger, stabiler und schneller läuft. der verbrauchte platz dafür ist ja nun auch minimal.
aber ggf ist das einfach nur nicht klar kommuniziert, was du nun erklärt hast. ich nehme ja nun schon lange derlei Systeme, als FULL! aber das war mir bis heute nicht klar.
danke
uwe

na toll. vielen dank für den rat. das Ergebnis:

swap_pager: indefinite wait buffer: bufobj: 0, blkno:51369*, size: 32768*

* je Zeile unterschiedliche werte.

auch mit einer swapdatei (4096MB) auf einer der beiden Platten keine Abhilfe, über kurz ode rang bleibt das system hängen.
toll!

ein stabiles System ist natürlich auch eine Frage der eingesetzten Hardware und ob diese auch von FreeBSD 100% unterstützt wird.
Bei einem low budget Mainboard wie dem ASRock Q1900-ITX kannst du mehr oder weniger Glück oder Pech haben. Bei Server-grade Hardware ist die die Stabilität entsprechend höher.
Wenn Du nur eine "Musikabspielkiste willst, dann stopf doch einfach eine große Festplatte in oder an den Dudel-iMac und gut ist es.

hi crowl,
danke für den Beitrag.
die idee, platten an den iMac zu hängen ist keine Lösung. denn wenn man jedwedem, ob in heimischer Familie, oder gar zb hinterm kneipentresen den Zugang zu den playlists gewährt und veränderungsrechte dazu hat, wird nichs am ende des Tages so sein wie am morgen. es entsteht völliges chaos. firefly bietet ja genau das passende: nicht veränderbare playlists.

witzigerweise habe ich (u.a.) auch ein Q1900-ITX als Testrechner im Einsatz, mit Ubuntu drauf. Das Ding läuft denkbar instabil. Beim E350M1 hatte ich keine Hänger und Abstürze.

hi crowl,
da hast du das Brett verwechselt.


s.o.: Der ITUNESNEU ist ein intel mini itx board (D510M0) mit atom (D510) drauf und 4GB ram

kreuzberger wrote:na toll. vielen dank für den rat. das Ergebnis:

swap_pager: indefinite wait buffer: bufobj: 0, blkno:51369*, size: 32768*

* je Zeile unterschiedliche werte.

...

auch mit einer swapdatei (4096MB) auf einer der beiden Platten keine Abhilfe, über kurz ode rang bleibt das system hängen.
toll!

Kurzer Zwischenstand:
Ich bin weiter an dem Thema dran.
Am Anfang hatte ich dir ja geschrieben, daß wir mit der Embedded-Installation eine besser definierte Umgebung haben, und das wir dann das Kernproblem genauer angehen können.

Das ist jetzt auch eingetreten, denn jetzt bekommst du zumindest aussagekräftige Fehlermeldungen (z.B. "swap_pager: indefinite wait buffer").

Ich habe mich am Wochenende (auch aus anderen Gründen) mit dem Thema "Swapping" in den neuen N4F-Versionen beschäftigt, denn da hat sich anscheinend einiges geändert.

Bei deinem Problem scheint es sich um mehrere Teilprobleme zu handeln, welche sich, nach meiner Einschätzung, durchaus lösen lassen.

Ein wesentlicher Faktor scheint dabei die Anzahl der Dateien / die insgesamte Datenmenge zu sein. Kannst du dazu mal ein paar Werte nennen?

Du hast ja selbst schon eine Ahnung in der Richtung:

kreuzberger wrote:gibt es da irgendwelche Erfahrungswerte, ob es da ne Begrenzung der Anzahl der songs / mp3-dateien gibt, ab wann das system Schwierigkeiten macht?

Ja, diese Erfahrungswerte wird es geben, wenn wir dein Problem gelöst haben

Ich weiß jetzt, daß dein System 4GB RAM hat.
Wie groß ist der Swap-Bereich? (nur der Standard-Swap der Embedded, nicht deine eigene Swap-Datei!)
Wie viele Audio-Dateien befinden sich in den eingetragenen Verzeichnissen?
Wie äußert sich der Fehler?

Sei bitte etwas geduldig. Erwarte nicht sofort eine fertige Lösung. Sehr wahrscheinlich müssen wir das Problem weiter eingrenzen, und dabei mehrere Schritte durchlaufen.

Grüße
Princo

Hi Princo,

aber bitte gerne doch. Wer hätte das gedacht, dass sich ein netter Kerl wie du an der Stelle soo viel Mühe gibt. Ich bin ja schon im positiven Sinne überrascht.

Ja, das System hat 4GB ram, das hatte ich aber doch aber in der aller ersten Eingabe ganz oben mitgeteilt, wie die Hardware aussieht. Ausser, dass da nun 2 stück 1,5TB HDD drin sind hat sich nix geändert.
Ich dachte eben, das Intel Board ist eigentlich die optimale Wahl, was unterstützte Hardware angeht.
Soweit ich mich recht erinnere habe ich alle Mainboardfunktionen per Bios abgeschaltet, die man nicht braucht:
als Sound is aus.

Derzeit zählt firefly knapp 35.000 mp3-dateien. Ich hatte auf deutlich älterer hardware auf meinem alten, vorhergehenden "iTunes-Server" (MSI-6741 mit einem alten Pentium single-core, 1,5GB RAM, 2 Hdd, 100MBit-LAN, System 9.0irgendwas) aber auch schon 150.000 und mehr, und der lief weitgehend stabil als full-Installation. Ich hatte den austauschen wollen um moderne Stromspartechnik einzusetzen. (hätte ich das blooooss nicht gemacht)
Wie groß der swap-bereich war kann ich nicht sagen, Ich habe die swap-datei nun auf 4GB eingestellt, also entsprechend dem physikalisch vorhandenen RAM.
Ich setze das nachher mal wieder zurück um zu sehen was er ggf vorher hatte, bzw selbst einsetzte.

Derzeit kann ich das system normal starten, und per Mac-Rechner über iTunes die Playlists laden. ich kann sogar eine weile lang Musik abspielen. Zur Kontrolle hab ich an dem Intel-Board ein Monitor angeschlossen. Da sehe ich dann recht bald diese Swapping-Fehlermeldungen. das geht ne ganze weile gut, bis irgendwann mitgeteilt wird: Swapbereich Full. Sehe ich dann im Web-Interface nach ist dem NICHT so. Trotzdem habe ich dann aber längst immer häufiger das Problem, dass er nicht durchgängig abspielt, sondern als hätte er Pufferschwierigkeiten mal ne halbe, mal minutenlang still bleibt, bis er dann irgendwann ganz verstummt.
Mit einem firefly Neustadt lässt sich das dann ggf. beheben. macht aber keinen spass.

Ich beobachte diese Swapping-Fehler sogar wen der Rechner einfach so eingeschaltet untätig so rumsteht.

Heute hatte ich bereits mehrfach das Problem, dass firefly bereits beim einlesen der playlists abstürzte.

ich hatte mal etwas herumgesucht und das:
http://de-bsd-questions.de.freebsd.nark ... re-timeout
gefunden. ich hab aber zu wenig Ahnung vom Systemunterbau ob das nun irgendwie brauchbar ist als info.Zeitweise kam ich wegen der angezeigten Swapping-Probleme nicht mal mehr auf des Web-Interface, lat Monitor Lief das system aber noch.

Wenn man dem Problem nicht auf die schliche kommt wäre ich geneigt wieder ein älteres System einzusetzen, weiss bar reicht welches dann optimal wäre.
Das Ziel ist ja wie gesagt ein mögliches stabiles mp3-Streaming-Kästchen mit Playlists bereit zu stellen.
uwe

Ich beobachte diese Swapping-Fehler sogar wen der Rechner einfach so eingeschaltet untätig so rumsteht.

hmmm, hast Du schonmal einen Memtest durchgeführt?
und/oder einen burn in, wie Princo ihn hier beschrieben hat:
viewtopic.php?f=93&t=7085

ich mag vielleicht falsch liegen, aber für mich sieht das eher wie ein Hardware Problem aus.

Noch ein kurzer Zwischenstand:
Meine Tests sind insoweit durch, und ich kann das Problem als "gelöst" vermelden.
Es handelt sich im Kern um ein "Nicht-Problem".
Was damit gemeint ist, und wie der Lösungsweg dazu aussieht, muß ich etwas detaillierter ausführen, und da weiß ich nicht, ob ich das heute oder morgen schaffe.

Stay tuned!

Grüße
Princo

Princo,

oh .. gott! was kommt da auf mich/uns zu?


bei dem ganzen Projekt kommt mir mehr und mehr der Gedanke sowas mal ausführlich für laihen zu dokumentieren. also das projkt superstabiler iTunes-Server.

kreuzberger wrote:oh .. gott! was kommt da auf mich/uns zu?

Keine Angst, alles halb so wild.

Am letzten Wochenende hatte ich mich mit dem Thema "Swap" etwas intensiver auseinander setzen müssen, da mit der N4F-Version 9.3.0.2 das Swapping nicht mehr so funktionieren wollte, wie noch mit der Version 9.1.0.1.

Bei der älteren Version konnte man nämlich noch ein ZFS-Volume als Swap hernehmen (obwohl davon abgeraten wird).

Bei meinen Experimenten bekam ich einmal auch die von dir erwähnte Fehlermeldung mit "swap_pager: indefinite wait buffer:...".

Diese Meldung kam aber nur, wenn ich händisch mit swapon/swapoff zwischen verschiedenen Swap-Bereichen hin und her gewechselt habe.

Als du dann geschrieben hast, daß du auch mit einer Swapdatei keinen Erfolg hast, war mir dann auch klar, weshalb das bei dir nicht funktionieren kann.

Dazu kommt noch meine Vermutung, daß du möglicherweise deine alte Config-Datei weiter benutzt hast(?) Möglicherweise hast du dort im System|Advanced Bereich Anpassungen vorgenommen, welche sich in der neuen N4F-Version negativ auswirken.

Meine derzeitigen Arbeitsthesen:
1. In den aktuellen N4F-Versionen geht es nicht ohne Swap.
2. Swap geht nicht mit ZFS-Volumes, und auch nicht mit einer Swap-Datei.
3. Swap geht nur mit eigenen Swap-Partitionen.
4. Swap sollte beim Systemstart eingebunden sein, ein Wechsel der Swap-Einstellungen ohne anschließenden Neustart kann Probleme bereiten.
5. Auch wenn der Swap korrekt auf der System-Status Seite angezeigt wird, heißt das noch lange nicht, daß er auch funktionieren wird.
6. Das System swappt auch, wenn eigentlich noch genügend freier Arbeitsspeicher vorhanden ist.

Vorteil bei korrekt eingerichteten Swap:
Das System läuft sehr stabil. Auch bei hoher Swap-Beanspruchung reagiert das Web-Gui noch. Das System "killt" selbstständig marodierende Prozesse (was erwünscht ist).

Jetzt die Nachteile:
Bei N4F kann man über das Web-GUI keine Swap-Partitionen einrichten.
Standardmäßig wird bei der embedded-Installation auf einem USB-Stick dort eine Swap-Partition eingerichtet, und auch genutzt (hinterher nicht mehr abschaltbar).
Swapping auf einen USB-Stick finde ich nicht so prickelnd. Außerdem verletzt es das bisherige Konzept, daß auf dem USB-Stick nur die Config-Datei geschrieben wird, und der Stick ansonsten tabu ist.

Gut, man kann die embedded-Installation auch ohne Swap vornehmen, aber danach muß man ja irgendwo eine Swap-Partition anlegen können.
Dafür gibt es in N4F keine Möglichkeit. N4F ist so aufgebaut daß immer die ganze Festplatte genutzt wird. Es gibt hier kein Partitionsmanagement.
Richtig bitter ist das besonders für ZFS-Nutzer, die müssten zwingend eine weitere Festplatte einbauen, wenn sie nicht auf USB swappen wollen.

Ich kann nur hoffen, daß es für dieses Problem bald eine bessere Lösung geben wird.

---

So, nachdem ich mich länglich über deine alten und neuen Problemursachen ausgelassen habe, möchte ich jetzt zur eigentlichen Problemlösung kommen.

Dazu muß ich noch sagen, daß ich diese Lösung eigentlich nicht empfehle, weil sie dem Konzept der strikten Trennung von System und Daten entgegensteht, und System-Updates u.U. problematisch werden können.

Die "Lösung" heißt "Embedded-Installation auf Festplatte" (mit Daten und Swap).

Einfach vom Live-USB-Stick starten, Punkt 9 und danach Punkt 1 auswählen, danach Quell- und Ziel-Laufwerk auswählen, und ansonsten die Standard-Werte übernehmen.

Im Prinzip wie eine Full-Installation, nur ohne die Nachteile. Du kannst das natürlich auch auf deine "große"-Festplatte installieren, mußt dann aber die Daten neu aufspielen.

Meine Beschreibung geht davon aus, daß du die Embedded-Version auf die große Festplatte spielst, auf der später auch die Musikdateien liegen werden.

Nach der Installation konfigurierst du die IP-Adresse, und gehst in das Web-GUI.
Alle weiteren Ausführungen gehen von einem frischen System aus, bei dem die ganzen Dienste auf ihren Standard-Werten stehen!

Dort gehst du in Disks|Management und fügst deine Festplatte (ada0) hinzu. Bei "Preformatted file system" mußt du "UFS" auswählen.
Du darfst keinesfalls die unteren Buttons benutzen!

Danach gehst du in Disks|Mount Point und fügst einen Eintrag hinzu:
Type: Disk
Disk: Deine Festplatte auswählen.
Partition number: 3
File system: UFS
Mountpoint name: Daten (oder was immer du magst, ich werde nachfolgend den Begriff "Daten" verwenden)
Access restrictions
Owner: ftp
Group: wheel
Mode: Alle Haken setzen, bis auf write bei Others.

Dann in Services|CIFS/SMB|Settings:
Max Protocol: SMB2 (kannst du später auf SMB3 ändern)
Dos charset: CP850 (ich mag das so)
Bei Advanced settings:
Null passwords: Haken setzen
AIO: Haken setzen

Dann in Services|CIFS/SMB|Shares:
Name: Daten
Comment: Daten
Path: /mnt/Daten
Recycle bin: kein Haken
Shadow copy: kein Haken

Nicht wundern: das sind die Einstellungen für ein "offenes" NAS. Das ist sicher nicht das, was du später haben möchtest. Aber das kann man später leicht auf Benutzerverwaltung umstellen. Mir geht es hier erstmal um eine einfache Installation, damit du sehr schnell deine Firefly-Konfiguration testen kannst.

Jetzt kannst du dich mit deinem Dateimanager auf die Freigabe "Daten" verbinden.
Lege dort die beiden Verzeichnisse "Audio" und "system" an. Ja, "system" in Kleinbuchstaben!
Lege im Verzeichnis "system" das Unterverzeichnis "UPNP" an.

Fülle jetzt dein NAS im Verzeichnis "Audio" mit deinen Musikdateien.

Erst wenn das Befüllen abgeschlossen ist, machst du dich an die Konfiguration von Services|iTunes/DAAP (vorher ergibt das keine Sinn).

In Services|iTunes/DAAP machst du dann folgende Einträge:
Database directory: /mnt/Daten/system/UPNP
Content: /mnt/Daten/Audio
Rescan interval: Das kannst du entweder auf dem Standard-Wert lassen, oder auf 0 setzen. Bei 0 mußt du dich selbst um das Rescanning kümmern. Ich würde eher zu 0 tendieren.

---

Du obige Konfiguration entspricht meinem Testaufbau, den ich zur Eingrenzung deines Problems vorgenommen habe.
Dafür habe ich ein 64Bit-System mit 4GB-RAM und einer 300GB-Festplatte genommen.
Auf die Festplatte habe ich ca. 18.000 mp3 und flac Dateien aufgespielt (~250GB).
Dabei habe ich das System in den drei Phasen Befüllen, Indizieren, Abspielen genau beobachtet.
Während des Befüllens (was ich nicht per SMB, sonder mit rsync gemacht habe), hatte ich eine recht hohe Systemauslastung, und recht schnell Swapping, wobei der Swap-Bereich bis maximal ~111MB genutzt wurde, und sich auch nicht weiter veränderte.
Beim Indizieren der Audio-Dateien durch Firefly gab es nur eine sehr niedrige Systemauslastung, das System swappte erst nach einiger Zeit, und nahm dabei sehr viel weniger Swapspace in Anspruch als beim Befüllen (~16MB).
Bein Abspielen per Firefly gab es keine nennenswerte Systembelastung, und das System swappte auch nicht.

Neben den o.a. Rahmenbedingungen für ein sauber funktionierendes Swap-System, scheint mir bei Firefly noch ein weiterer Aspekt von Bedeutung zu sein:
Dabei geht es um die Funktion des Rescannings.
Ich hatte mir das vor einigen Jahren mal genauer angeschaut, und zwar sowohl für Firefly, als auch für fuppes.
Damals bin ich zu dem Ergebnis gekommen, daß das automatische Rescanning nicht funktioniert.
Meine pragmatische Lösung dafür ist, einfach die jeweiligen Database-Dateien zu löschen, das NAS neu zu starten, und die Index-Dateien automatisch neu aufbauen zu lassen. Das geht idR. schneller als ein Full Rescan, daher auch mein Tipp, das Rescan interval auf 0 zu setzen.

Noch ein Tipp: Über die Freigabe kannst du das Verzeichnis system/UPNP einsehen.
Dort befindet sich die Datei "songs3.db".
Wenn sich dort auch die Datei "songs3.db-journal" befindet, dann macht das System gerade seinen Erstindizierungslauf.
Wenn die "songs3.db-journal" dort nicht mehr erscheint, dann ist der Erstindizierungslauf abgeschlossen.
Wenn man die "songs3.db" löscht, und das NAS neu startet, wird komplett neu indiziert. Das geht übrigens ziemlich fix.

---

Ich hoffe, daß dir meine Ausführungen bei der Ausmerzung deines Problems helfen.
In meiner Testumgebung funktionierten die beschriebenen Schritte ohne Probleme, und auch beim Swapping gab es keinerlei Fehlermeldungen (wenn man die Finger davon läßt).
Das Web-GUI reagierte auch unter hoher Belastung, und fror nicht ein. Das System war zu jedem Zeitpunkt stabil.
Ich hoffe, daß ich bei meiner Beschreibung keinen wesentlichen Punkt vergessen habe.
Falls doch, dann bitte ich vorab um Entschuldigung.

Grüße
Princo

Also ... Stand der Dinge:

ich hab ein Komplettbackup aller Daten gemacht und eine der beiden Platten ausgehängt.
Dann hab ich per USB Stick das system als embedded (Installationsauswahl 1) auf eine der platten frisch drüberinstalliert, dabei die swap partition mit 4096KB anlegen lassen.
Das System 9.3.0.2 - Nayla (Revision 1480) von der Platte neu gestartet, und auf DHCP umgestellt (bei mir läuft ein Win server 2008 R2 als virtuelle Maschine auf einem mac Mini, der auch DHCP macht. Hier sind alle Server im Netz per Reservierung vermerkt)
Hab dann "per Hand" (also nicht mit den unteren buttons) die erste Pladde hinzugefügt und als DATEN01 (Partition 3) angehängt, Einhängepunkt heisst dann auch DATEN01.
(Die zweite Platte ist noch immer abgezogen)
Hab dann meinen einzigen Standard-USER als Admin + Wheel inkl. ssh Zugriff eingerichtet.
Nun hab ich den CIFS Dienst (SMB) eingeschaltet und eine Festplattenfreigabe gemacht auf DATEN01, mit dem Namen DATEN01. Ich hab Asynchrones I/O eingeschaltet und die Parameter erstmal auf 4096 belassen.
Hab nun angefangen meine Backups, also die Musikdaten in ein Verzeichnis ITUNES-MUSIK (mnt/DATEN01/ITUNES-MUSIK) zu kopieren, wo es dann dadurch div. Unterordner geben wird.
Das Swaping hab ich unverändert gelassen wie nach der Installation.
Die Kopiererei läuft derzeit OHNE Fehlermeldung auf dem Kontrollbildschirm (20 ....30 MB/s).

so, neuer stand der dinge:

nach dem ich nun den firefly in betrieb genommen habe, also erstmal nur Daten hab zusammensammeln lassen, folgende Fehlermeldung:

swap_pager_getswapspace(16): failed

kreuzberger wrote:swap_pager_getswapspace(16): failed

Gut.
Warum nutzt du eigentlich die Revision 1480 und nicht die 1681? (Ändere jetzt nichts dran.)

Der nächste Schritt ist jetzt, zu testen, ob der Swap-Mechanismus überhaupt bei dir funktioniert.

Dies läßt sich am Besten durch das temporäre Anlegen einer Ramdisk durchführen.
Dazu werden wir nacheinander die Ramdisk mit verschiedenen Größen anlegen, und jeweils wieder löschen.

Vorbereitung:
Gehe bitte in Status|Services (einfach direkt auf den Button "Services" im Web-GUI klicken).

Deaktiviere dort bitte ALLE Services, bis auf SSH. Ja, auch CIFS/SMB muß abgeschaltet werden!

Aktiviere und konfiguriere SSH bitte so, daß du dich als root anmelden kannst.

Reboote dein NAS.

Testdurchführung:
Log dich über das Web-GUI ein. Bleib auf der Status-Seite.

Verbinde dich dann per SSH-Terminal-Session als root mit deinem NAS.
Gib dort ein.
Damit können wir noch Werte erhalten, auch wenn sich das Web-GUI nicht mehr aktualisiert.
Interessant ist die fünfte Zeile von oben (Swap:).

Mache dann eine weitere Terminal-Session auf, verbinde dich als root mit dem NAS.
Du solltest jetzt folgenden Zustand haben:
1. Ein Browserfenster mit der Status-Seite vom NAS.
2. Ein Terminal-Fenster mit dem laufenden "top".
3. Ein Terminal-Fenster mit dem NAS-System Prompt.
4. Einen eingeschalteten Monitor an deinem NAS.

Auf der Status-Seite (1.) sollte ein Memory usage von ~4% angezeigt werden.

Jetzt gibst du in das Terminal-Fenster (3.) diesen Befehl ein: Der Befehl braucht ein paar Minuten, da er das RAM langsam füllt.

Zu erwartendes Ergebnis:
Der Balken bei Memory usage wandert langsam bis zu einem Wert von ~56%
Der Swap wird nicht genutzt.
Nach ein paar Minuten bricht der Befehl mit "cat: stdout: No space left on device" ab. Das ist richtig.

Jetzt mußt du die Ramdisk löschen: Memory usage sollte wieder auf ~4% sinken.

Erneuter Durchlauf (mit 4GB):
Gib den vorletzten Befehl erneut ein, aber ändere den Wert auf "size=4G".

Erklärung: Mit diesem Durchgang zwingen wir das System dazu, ein kleines bisschen zu swappen.
Wenn das Swapping bei dir funktioniert, sollte das keinerlei Probleme machen.

Zu erwartendes Ergebnis:
Der Balken bei Memory usage wandert langsam bis zu einem Wert von ~86%.
Danach wird der Swap genutzt (~700MB).
Top sollte jetzt auch die Swap-Nutzung anzeigen.
Auf deinem Console-Monitor sollte keine Fehlermeldung auftauchen.
Schau dir den Zustand in Ruhe an.

Lösche die Ramdisk. (Es ist ganz wichtig, die nach jedem Durchlauf zu löschen!) Achte dabei darauf, wie die Werte der Swap-Nutzung und von Memory usage sinken. Es ist normal, daß der Swap jetzt nicht ganz freigegeben wird.
Aus irgendwelchen Gründen bekommt "top" allerdings nicht mit, daß Swap freigegeben wurde. Beende "top" durch Eingabe von "q" und starte "top" neu.

Das war der reguläre Teil. Bis hierher sollte es dein System ohne Probleme geschafft haben.

Und jetzt gehen wir in den "bösen" Teil über.

Mache einen erneuten Durchgang, und setze dabei "size=7G".

Zu erwartendes Ergebnis:
Das ist etwas schwierig vorherzusagen, da ich nicht weiß, ob sich unsere beiden Systeme 100%ig gleich verhalten.
Es kann sein, daß es problemlos durchläuft.
Es kann aber auch sein, daß du die Fehlermeldung "swap_pager_getswapspace(16): failed" bekommst.
Selbst wenn diese Fehlermeldung kommt, kann es sein, daß dein System ansonsten noch funktioniert.

Lösche die Ramdisk.

Sollte dein System aber rumspinnen, dann mach einen Reboot, log dich im Web-GUI ein, mach wieder die beiden Terminalfenster mit "top" und dem System-Prompt. Dann mach ab hier einfach weiter.

Mache einen erneuten Durchgang, und setze dabei "size=9G".

Zu erwartendes Ergebnis:
Mit diesem Wert muß das System in irgendeiner Form crashen.
Sehr wahrscheinlich wird das Web-GUI nicht mehr funktionieren.
Außerdem werden möglicherweise eine oder sogar beide Terminal-Sessions gekillt.
Es kann sogar sein, daß man sich nicht mehr per Terminal-Session verbinden kann, weil auch der SSH-Dienst gekillt wurde.

Aber,
das System sollte sich zumindest noch über die Console rebooten lassen, also nicht völlig einfrieren.

Die Tests sind jetzt abgeschlossen. Reboote dein NAS, und aktiviere die Dienste wieder. Firefly (iTunes/DAAP) solltest du aber noch deaktiviert lassen. Beobachte, ob dein System mit deaktivierten Firefly anfängt zu swappen, oder ob die Swap-Fehlermeldungen noch kommen.

Interpretation der Ergebnisse:
Dein System hat den Swap-Test bestanden, wenn die jeweils zu erwartenden Ereignisse eintreten.
Es ist schlimm, wenn dein System die beiden ersten Durchläufe (mit 2G und 4G) nicht schaffen sollte.
Es wäre doof, wenn dein System bei den beiden letzten Durchläufen einfrieren würde (also auch auf der Console direkt am NAS nix mehr zu machen ist.

Besonders wichtig ist der zweite Durchlauf (mit 4GB). Teile mir bitte mit, ob das System tatsächlich swappt, und wie hoch der Swap-Used-Wert ist.

nächste Schritte:
Wenn wir wissen, ob dein Swapping richtig funktioniert, können wir uns dem nächsten Schritt der Problemlösung zuwenden.
Dabei habe ich schon einen ganz konkreten Verdacht, und wenn der zutrifft, dann ist die Lösung sogar ziemlich banal.

Meine Fragen:
- Hast du das Verzeichnis system/UPNP angelegt, und Firefly so konfiguriert, daß dort die Datenbank angelegt wird, wie ich es im meinem vorherigen Post erklärt hatte?

- Wie sind die oben beschriebenen Tests verlaufen?

- Ich brauche den Swap-Used-Wert aus dem zweiten Durchgang (mit 4GB).

Noch eine Bitte:
Führe die Tests bitte ganz exakt so durch, wie ich es beschrieben habe. Wandle da nichts ab. Deine Daten und deine Konfiguration werden durch diese Tests nicht verändert.
Dein Cronjob zur Löschung der Playlisten sollte übrigens nicht aktiv sein. Den habe ich extra bei meiner Anleitung im Vorpost nicht erwähnt.
Mach das bitte alle genau so, wie ich es geschrieben habe. Falls ich mich irgendwo vertan oder unverständlich ausgedrückt habe, dann frag lieber nach, bevor du mir evtl. falsche Ergebnisse nennst.
Dann kriegen wir dein Problem sehr wahrscheinlich ganz schnell gelöst.

Grüße
Princo

hi allerseits,
Hi Princo,

ohne das ich inzwischen deine ratschläge oben weiter ausführte muss ich nun den firefly alle neeese lang komplett neu starten. man verliert echt die Laune.

Hallo kreuzberger,

Das da oben sind keine Ratschläge, sondern es handelt sich um einen Test, ob dein Swap funktioniert.
Durch den Test wird das Problem nicht gelöst, sondern besser identifiziert.
Du schreibst bisher nämlich nur über die Fehlermeldung, aber nicht so richtig darüber, ob er ansonsten korrekt swappt.

Der eigentliche Fehler liegt ganz woanders, und würdest du die 15 Minuten für den Test opfern, kämen wir schneller zur Behebung des Problems.

Grüße
Princo