PIMP
Moderator
|
totally awesome
|
GrandAdmiralThrawn
XP Nazi
|
Das kann ich erst bestätigen, wenn mal die Initialisation fehlerfrei durchrennen würde.
|
.dcp
notamodbuthot
|
Und hier haben wir ihn, in all seiner Pracht:
wow. so sexy
|
x37
xxx-xxxxxxx
|
Warum verwendest die Komprimierung?
|
XXL
insomnia
|
Warum verwendest die Komprimierung? bringt bei einem 500 gb laufwerk knappe 20gb (kommt auch drauf an was drauf ist) ich denke mal bei so einem riesen teil kriegst noch mehr raus würd mich auch mal interessieren, ich hab derzeit auch sowas um die 5 tb aber verteilt über unmengen externe, das alles auf einem raid wär schon interessant
|
EG
thinking with portals
|
Das kann ich erst bestätigen, wenn mal die Initialisation fehlerfrei durchrennen würde. Hoff das Array hat nix. Wär schad..! Freu mich schon auf erste Werte.
|
x37
xxx-xxxxxxx
|
bringt bei einem 500 gb laufwerk knappe 20gb (kommt auch drauf an was drauf ist) ich denke mal bei so einem riesen teil kriegst noch mehr raus
würd mich auch mal interessieren, ich hab derzeit auch sowas um die 5 tb aber verteilt über unmengen externe, das alles auf einem raid wär schon interessant ich mein das bremmst ja ungemein, oder bin ich da net mehr up to date?
|
GrandAdmiralThrawn
XP Nazi
|
Es bremst, ja. Aber da wird (so vermute ich) noch mehr als genug Leistung übrig bleiben.
Es ist so, daß selbst komprimierte Inhalte (AVI's, mp3s, JPEGs) noch soweit preßbar sind, daß da wirklich mehrere GB Ersparnis rausschauen. Und unkomprimierte Inhalte werden natürlich um ein schönes Eck kleiner. Wäre schade, das auf einem Storagearray zu verschwenden.
Für die Bereiche, wo dann wirklich mehr Leistung als Platzersparnis gefragt ist, kann ich immer noch einzelne unkomprimierte Ordner einrichten! Aber per default sollte alles, was da drauf landet, durch NTFS komprimiert werden.
|
semteX
Risen from the banned
|
wennst es via gbit ethernet anbindest ist das ein schändliches verbrennen von performance :P
|
GrandAdmiralThrawn
XP Nazi
|
Eine Ethernet Anbindung via SMB würde mich wohl mehr Leistung kosten, als die NTFS Kompression. Außerdem hasse ich per SMB eingebundene Netzlaufwerke.. Jedes Mal, wennst das Laufwerk etwas länger nicht benutzt, und dann wieder draufklickst, dauerts ein paar Sekunden, bis er wieder refreshed. Da werd ich irre! Wenn ich draufklick muß das SOFORT da sein, rofl. Zudem bekomm ich schon über mein 100MBit Ethernet irgendwie keine gscheite Transferleistung zusammen. Ich müßte meine restliche Infrastruktur auf GBit bringen, und noch viel mehr Geld ausgeben, um noch einen Fileserver zu bauen (habe jetzt einen Web/-FTP Server, der schon per Ethernet und SMB angebunden ist). => NEIN! Edit: Außerdem kann ich mir bei NTFS Komprimierung wie gesagt selektiv aussuchen, welche Bereiche langsamer/kleiner werden sollen, und auf welchen ich vollen Speed brauche. Diese Option hätte ich bei der Ethernetanbindung nicht zur Verfügung...
Bearbeitet von GrandAdmiralThrawn am 08.06.2007, 07:17
|
GrandAdmiralThrawn
XP Nazi
|
Es hat gedauert wegen der dauernden Controller "Resets" (Treiber oder Firmware Problem?), die immer ein Rollback des Initialisierens bedeuten, aber endlich... nach 2 Tagen des lahmen Background-Inits: Initialisationsprozess: Und das war's, 100% einsatzbereit ohne Slowdowns: Und so sieht's hier momentan aus, da das alte RAID derweil ja noch im Tower steckt:
|
TOM
Super ModeratorOldschool OC.at'ler
|
benchmarks plz :]
|
GrandAdmiralThrawn
XP Nazi
|
Ein bisserl müßts euch noch gedulden, ich kopiere noch meinen alten Datenbestand, MS RoboCopy hackelt grade vor sich hin. Die großen Files sind bald alle drüben, dann kommen die vielen lästigen kleinen Files... (Er kopierte schon während des Inits) 790GB von 1.35TB sind drüben. Das kann schon Mal bis Sonntag dauern.. Hoffentlich ned länger. Edit: Uh oh.. Habe zum Test mal von beiden Raptor Disks Daten rüber geschossen (die müssen sowieso rüber). Jeweils ca. 20GB, von der einen Raptor massig kleine Files und von der anderen massig große. Fazit: Jo, flott, aber unter so schwerer Last vermehrt diese "Controller Reset occurred" Meldungen im Log. Im Betrieb äußert sich das durch kurze "Aussetzer", Cache Flushes, und dann gehts weiter. Gefällt mir nicht. Resultiert zwar in nichts kritischem (die Meldungen haben auch nur "INFO" Level, nicht Warning oder Error), doch habe ich Mal mit allen Infos zu Treibern, HBA und Disk Firmwares und Logfiles den 3Ware Support kontaktiert. Mal sehen.. Das könnte schließlich auch Benchmarkwerte negativ beeinträchtigen.
Bearbeitet von GrandAdmiralThrawn am 09.06.2007, 00:13
|
coolsn11
1k senseless posts
|
hört sich ja nicht besonders gut an. Über die Benchmarkwerte würd ich mir jetzt keine Gedanken machen, wenn immer noch Meldungen im Log stehen
|
GrandAdmiralThrawn
XP Nazi
|
Der Fehler kann wenigstens nicht in Datenverlust o.ä. ausarten. SO, heute ist alles fertig geworden, und die HDDs wurden auch umgebaut, 3 Stunden Arbeit. Dafür fein säuberlich. Und hier, analog zu Tilmanns Thread: Man beachte neben der offenkundigen Performance vor allem auch die quasi non-existente CPU Belastung! CPU ist übrigens ein C2D E6600. Edit 2: Im Vergleich dazu noch meine 150GB WD Raptor, meine Systemplatte: Edit 3: Hier noch ein ATTO Benchmark des Arrays. Ich wußte nicht, welche Einstellungen hier zu wählen sind, aber bei den meisten Benches wurden die Platten nicht Mal angetastet, schien sich alles im Cache abzuspielen (tlw. 300MB/s Schreibleistung und so Humbug) Mit "I/O Comparison" ists mir dann gelungen, bei dem Test schreibt er sofort direkt auf die HDDs, als Pattern hab ich Mal "Random" genommen. Wenn mir wer sagen kann, wie ich das eigentlich einzustellen habe, immer nur her mit den Infos! Bei dieser Einstellung liegt der Spitzenwert beim Schreiben bei 50MB/s. Die Lesewerte kann man getrost ignorieren, gab beim Lesen keinen Diskzugriff: Edit: Welches Tool nehme ich sonst am besten, um Schreibleistung zu benchen?
Bearbeitet von GrandAdmiralThrawn am 10.06.2007, 04:17
|