Hallo Erik,

...

Die Festplatte, die ich jetzt verwende, schafft im ungünstigsten Fall ca. 30MB/s lesen oder schreiben (wenn nur ein Prozess linear liess/schreibt).

Womit ermittelt?

dd_rescue /dev/hda4 /dev/null -b 1M mit init=/bin/bash (und umgekehrt mit dd_rescue /dev/zero /dev/hda4) und dann ganz gespannt auf die Zahlen geschaut. Dabei hat sich auch bestätigt, dass die Platten im inneren Bereich langsamer sind - muss ja auch. Das Streaming funktioniert auch problemlos mit den angesprochenen 24MB/s.

Ich würde zuerst ein Hardware-RAID 0 auf zwei SCSI-Platten einrichten. Wenn die Daten wichtig sind besser RAID 0/1 mit 4 Platten.

Ok, das wäre eine Lösung - aber leider nicht durchführbar. Ich wollte nach Möglichkeit mit einer Platte für die Daten hinkommen - RAID nur wenn es nicht anderes geht. Da die ganze Sache in einem Gerät verbaut ist, bin bin ich Einschränkungen bei der Leistungsaufnahme/Wärmeabgabe und Größe unterworfen.

Und dann tar(1) direkt auf das Devive probieren.

Ich verstehe allerdings nicht ganz, welchen Vorteil mir das tar bringt. Wenn ich beispielsweise nur ein (großes) File löschen will, hilft das IMO auch nicht. Nochmal zum Verständnis: Es geht darum, 4-8 große Files beliebig zu speichern, zu löschen oder zu lesen. Ich brauche nur reguläre Files, keine Verzeichnisse, Links, Devices etc. und einen garantierten Durchsatz. Der Plattendurchsatz reicht theoretisch. Jetzt brauch ich nur noch ein Dateisystem, dass mir den Durchsatz nicht kaputt macht, wenn es ein wenig fragmentiert ist.

Gibt es noch weitere Vorschläge?

Sebastian

Hallo,

Die kanonische Antwort lautet: Echtzeit-OS + Echtzeit-FS. ;-)

Du hast recht.

Falls Du vorher weißt, wie lang der Strom ist, könntest Du ein File vorher anlegen und mit der entsprechenden Datenmenge füllen. Dann muß das FS beim Schreiben keine Blöcke hinzufügen, da die ja schon da sind. Außerdem kannst Du den Datendurchsatz schon vorher testen, da ja die zu benutzenden Blöcke dem FS bekannt sind. Außerdem würde ich dafür eine separate Platte nehmen, damit der "Datensammler" der einzige Prozess ist, der darauf zugreift.

Ok, den Ansatz mit der vorherigen Belegen des Datenfiles habe ich auch schon verfolgt. Allerdings habe ich generell ein wenig Bauchschmerzen, wenn ich von vornherein nicht 99,999%ig weiß, dass mir beim Schreiben niemand dazwischenfunkt und eventuell ein paar tausend Samples (ja, es geht um das Speichern von Daten aus einer AD-Karte) verloren gehen. Theoretisch wären ein anderer Ansatz (RT-OS) sinnvoller. Wenn man jedoch Nutzen und Aufwand abwägt ist Linux für mich die sinnvollere Wahl.

Eine Frage noch dazu in die Runde. Ich möchte mmaped IO auf das besagte File betreiben und weiss von vornherein, dass ich nur schreiben will. Jedoch wird natürlich der bereits existierende Dateiinhalt in den gemappted Speicher kopiert, obwohl ich den gar nicht brauche. Kann ich das unterbinden? Der Aufruf von mmap(2) will immer ein Filehandle auf dem auch gelesen werden kann. Den Speicherbereich als nur schreibbar markieren hilft auch nicht. (PS: alles auf 2.4er Kernel und 386)

Naja, 128 MB bei 24 MB/s ergeben 5 Sekunden Reserve. Da muß der Stepper aber ganz schön weit steppen...

Dass ist richtig - aber ich will auch eine groooße Platte verwenden ;-)

Mittlerweile habe ich auch ein paar Test gemacht und es nicht geschafft, einen Pufferüberlauf zu provozieren. Auch nicht auf einem Dateisystem, auf dem schon Daten wie Löcher im Käse auf der Platte verteilt sind. Ext2 hat bisher am Besten abgeschnitten (gegenüber Ext3 und ReiserFs - also welche mit Journaling). An XFS bastel ich noch.

Danke an alle, die bisher geantwortet haben,

Sebastian