LSI Raid Controller - Raid5 mit mehr als 3 Platten extrem langsam

Oje, 3ware... Waren zwar zuverlässig (hatte selber 6 Jahre einen 8506 
mit 10 Platten im Raid5), aber beim Schreiben im Raid5-Mode 
schnarchlahm. Das ist bei den späteren 9er-Versionen mit PCIe nicht 
signifikant besser geworden. Das Web ist voll mit allen möglichen Tips, 
die aber das eigentliche Problem nicht lösen (können). AFAIR war das 
wichtigste das Anschalten des Write-Caches, der ohne Battery-Pack nicht 
automatisch an ist. Dann gabs noch (unter Linux) ein paar 
/proc/sys/*-Tricks, aber über 30-40MB/s bei wirklich grossen Files bin 
ich nie gekommen. Falls das Linux ist, wäre ein Soft-Raid 
überlegenswert, die "kleinen" HW-Raid-Controller ala Areca oder LSI 
(Dell, ...) haben IMO inzwischen keine wirklichen Vorteile mehr und fast 
nur noch Nachteile.

Zu den /proc/sys/vm Tricks:
Ich hab in meiner rc.local z.b. folgendes stehen

1

# Komprimierte Ramdisk für Swap anlegen

2

modprobe zram num_devices=4

3

sleep 0.1

4

echo 1 > /sys/block/zram0/reset

5

sleep 0.1

6

echo $((1024*1024*2048)) > /sys/block/zram0/disksize

7

# Unkomprimierte Größe der Disk (bei mir 2Gb)

8

9

sleep 0.2

10

mkswap /dev/zram0

11

swapon /dev/zram0 -p 10

12

13

echo 95 > /proc/sys/vm/dirty_background_ratio 

14

# Wieviel % Des Freien Arbeitsspeichers dürfen insgessamt als 

15

# write Cache genutzt werden, bevor (vom Kernel) angefangen Wird die Daten auf die FP zu schreiben?

16

17

echo 90 > /proc/sys/vm/dirty_ratio 

18

# Wieviel % Des Freien Arbeitsspeichers dürfen von einem Einzelnen Programm als 

19

# write Cache genutzt werden, bevor es bei jedem schreiben direkt auf die FP schreibt?

20

21

echo 95 > /proc/sys/vm/swappiness 

22

# Swappe ungenutzte Programm(teile) oft 

23

# (bei 100 wären es immer, bei 0 niemals) aus, um platz für den Cache zu schaffen.

24

25

echo $((100*60*60)) > /proc/sys/vm/dirty_expire_centisecs 

26

# Daten können bis zu 1 Stunde lang ungeschrieben im Cache liegen.

27

28

echo $((100*60*10)) > /proc/sys/vm/dirty_writeback_centisecs 

29

# Alle 10 Minuten wird geprüft, ob zu alte Daten geschrieben werden müssen.

Beachtet werden muss, dass bei enem Absturz Extrem viele Daten verloren 
gehen können.
Mehr Details gibts hier: 
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

_Gast schrieb:
> (NAS4Free mit ZFS Dateisystem

Alternativ btrfs.

Vergleich ZFS/btrfs/ext4/XFS: "The results from the Fileserver profile 
in the Filebench experiment is showing that Btrfs has consistently the 
highest performance for all the disk setups whereas ZFS is showing the 
lowest performance."
https://www.diva-portal.org/smash/get/diva2:822493/FULLTEXT01.pdf

Bisher keine Probleme damit (debian, RAID 1).

A. K. schrieb:
> _Gast schrieb:
>> (NAS4Free mit ZFS Dateisystem
>
> Alternativ btrfs.

Das ist alles noch viel zu wenig abgehangen. Vor allem die Tools zur 
Reparatur (sofern überhaupt existent). Meine MD RAIDs habe ich bis jetzt 
immer noch repariert gekriegt. Wobei es meist darauf hinauslief, dem 
MD-Treiber zu verklickern daß er auch die Platten mitbenutzen soll, die 
geringfügig zu alt sind.

Als Filesystem empfehle ich xfs oder ext4.

Axel S. schrieb:
> Meine MD RAIDs habe ich bis jetzt immer noch repariert gekriegt.

Wobei ich es vorziehe, sie nicht erst kaputt zu machen. ;-)

Einen (unfreiwillig) simulierten Plattenausfall habe ich hinter mir, den 
hat btrfs gut überstanden.

Ich habe zudem ein gewisses Grundvertrauen in das 
transaktionsorientierte Arbeitsprinzip von COW Filesystemen. Weil die 
bestehende Daten grundsätzlich nicht überschreiben, sondern anderswo neu 
schreiben und (dem Prinzip nach) nur konsistente Zustände finalisieren.

Filesysteme alten Stils benötigen zwingend Reparaturtools, fsck oder 
Journalling, weil sie diese Eigenschaft nicht besitzen und daher bei 
crash/powerdown einen inkonsistenten Zustand hinterlassen.

> Ich habe zudem ein gewisses Grundvertrauen in das
> transaktionsorientierte Arbeitsprinzip von COW Filesystemen. Weil die
> bestehende Daten grundsätzlich nicht überschreiben, sondern anderswo neu
> schreiben und (dem Prinzip nach) konsistente Zustände finalisieren.

Wobei ich jetzt mit ext3 und ext4 auch keine besonderen Probleme hatte. 
jfs dagegen hatte nach einem unerwartetem Abschalten auf einmal 
Binär-Müll in ein paar /etc/-Config-Dateien, die ganz sicher nicht 
beschrieben wurden... Da nehm ich dann lieber noch FAT ;)

Georg A. schrieb:
> Wobei ich jetzt mit ext3 und ext4 auch keine besonderen Probleme hatte.

Wobei diese Filesysteme (wie auch NTFS) sehr die Geduld vieler Leute 
strapazieren können, wenn das Filesystem recht viele Files enthält und 
das System mal eben weg war. Privat ist das weniger problematisch, aber 
ein sehr länglicher fsck beim Powerup kommt @biz immer zum falschen 
Zeitpunkt.

> jfs dagegen hatte nach einem unerwartetem Abschalten auf einmal
> Binär-Müll in ein paar /etc/-Config-Dateien, die ganz sicher nicht
> beschrieben wurden... Da nehm ich dann lieber noch FAT ;)

JFS ist kein transaktionsorientiertes Filesystem. Wobei ich mit JFS/JFS2 
unter AIX bisher nur gute Erfahrungen gemacht hatte. Reparatur war kaum 
jemals nötig.

A. K. schrieb:
> Ich habe zudem ein gewisses Grundvertrauen in das
> transaktionsorientierte Arbeitsprinzip von COW Filesystemen.
...

> Filesysteme alten Stils benötigen zwingend Reparaturtools, fsck oder
> Journalling, weil sie diese Eigenschaft nicht besitzen und daher bei
> crash/powerdown einen inkonsistenten Zustand hinterlassen.

Es ist ein verhängnisvoller Irrtum, anzunehmen BTRFS oder ZFS bräuchten 
keine Reparaturtools, weil sie COW machen. Das ist nur knapp vor "ich 
brauche kein Backup, ich hab ja ein RAID".

Insbesondere zu diesen beiden Kandidaten möchte ich noch auf 
https://blog.fefe.de/?ts=a9f560e2 verweisen ...

Axel S. schrieb:
> Es ist ein verhängnisvoller Irrtum, anzunehmen BTRFS oder ZFS bräuchten
> keine Reparaturtools, weil sie COW machen.

Habe ich auch nicht behauptet. Es ist nur so, dass dabei anders als in 
klassischen Filesystemen vom Arbeitsprinzip her keine inkonsistenten 
Zustände auftreten. Inkonsistenzen sind damit eine Fehlfunktion, während 
sie in klassischen Filesystemen inhärent sind und durch Reparatur oder 
Journaling abgefangen werden müssen.

> Das ist nur knapp vor "ich
> brauche kein Backup, ich hab ja ein RAID".

Mir gefällt der besser: "Ich brauche kein Backup, ich hab ja fsck". ;-)

A. K. schrieb:
> Georg A. schrieb:
>> Wobei ich jetzt mit ext3 und ext4 auch keine besonderen Probleme hatte.
>
> Wobei diese Filesysteme (wie auch NTFS) sehr die Geduld vieler Leute
> strapazieren können, wenn das Filesystem recht viele Files enthält und
> das System mal eben weg war. Privat ist das weniger problematisch, aber
> ein sehr länglicher fsck beim Powerup kommt @biz immer zum falschen
> Zeitpunkt.

Hm, bei "mal eben weg" gibts eigentlich so gut wie nie einen fsck. 
Ausser man hat vergessen, max-mount-count/time passend zu verstellen. 
Oder das FS hat schon vorher was übles festgestellt... Bei uns gurken so 
200TB rum, von denen Radio/TV läuft, da würden längere Wartezeiten auch 
etwas betriebshinderlich sein ;)