lvm oder ext3 "write cache" enablen?

Ich hab eine etwas gefinkeltere Anforderung:

Linux System auf IBM HS21 Blade mit einer einzelnen SAS-Disk.
Die HS21 Blades haben kein Batterypack am Raid-Controller und somit auch keinen Write Cache, was eine extrem schlechte Write-Performance bei mehreren parallelen I/Os bedeutet.
Es gibt die Batterypacks auch nicht als H/W Option (anscheinend).

Wie könnte man hier jetzt einen Software-Write-Cache implementieren?
Datenkonsistenz ist mir Schnuppe, die lokale Disk wird nur als cache verwendet.

Sowas müsste sich doch über LVM oder vielleicht direkt über ext3 machen lassen...

Kennt hier jemand eine Möglichkeit dafür?

ext3 ist vielleicht nicht das optimale FS fuer deine Zwecke. Je nachdem wie viele Daten anfallen, ist vielleicht auch ein tmpfs moeglich?

Ansonsten wuerde ich an deiner Stelle mal einen Blick auf XFS werfen, und mir die Beschreibung der Tunables in /proc/sys/vm/ auf http://www.linuxinsight.com/proc_sys_hierarchy.html ansehen. Vielleicht ist was dabei, das dir bei deinr Sache hilft.

Software Writecache per se ist das zwar alles keiner, aber die Performance kannst du so ziemlich wahrscheinlich verbessern.

Das ist allerdings eine Frage des Controllertreibers; keine des Dateisystems oder des Volume Managers.

Du kannst die iSCSI parameter natürlich per hand tunen. Ich bin mir nicht sicher ob FreeNAS openiscsi oder das enterprise-iscsi-target verwendet, aber in beidem sollte ein tuning per Hand natürlich möglich sein. Außerdem sind 512MB buffer am iSCSI target uU nicht optimal. Verwendest du trunking/bonding und multi-path und eigenes VLAN oder eigenes LAN für die iSCSI SAN-Anbindung? Oder ist das ein rein virtuelles setup? Meiner Erfahrung nach reagieren viele iSCSI initiators sehr empfindlich auf disconnects und connection losses; oftmals ist das FS nach so einem Vorfall ziemlich kaputt.

Schon mal mit nilfs2[1] als filesystem versucht? Das bläst so ziemlich alles weg wenn es um write-performance geht (btrfs, ext4, xfs, reiser3, etc.). Beim letzten USENIX Storage workshop gabs schöne Messungen[2]. Nilfs2 ist ein log-structured-FS welches sich vor allem zum Ziel gesetzt hat seeks zu vermeiden und alle writes so gut wie möglich sequentiell zu erledigen. Seit 2.6.30 in mainline, fixes und dergl. in 2.6.31. Außerdem bietet es continuous snapshotting in O(1) Aufwand --- also auch sehr interessant am server.

[1]http://www.nilfs.org/en/about_nilfs.html
[2]http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf

Zitat von SYSMATRIX

Du kannst die iSCSI parameter natürlich per hand tunen. Ich bin mir nicht sicher ob FreeNAS openiscsi oder das enterprise-iscsi-target verwendet, aber in beidem sollte ein tuning per Hand natürlich möglich sein. Außerdem sind 512MB buffer am iSCSI target uU nicht optimal. Verwendest du trunking/bonding und multi-path und eigenes VLAN oder eigenes LAN für die iSCSI SAN-Anbindung? Oder ist das ein rein virtuelles setup? Meiner Erfahrung nach reagieren viele iSCSI initiators sehr empfindlich auf disconnects und connection losses; oftmals ist das FS nach so einem Vorfall ziemlich kaputt.

Schon mal mit nilfs2[1] als filesystem versucht? Das bläst so ziemlich alles weg wenn es um write-performance geht (btrfs, ext4, xfs, reiser3, etc.). Beim letzten USENIX Storage workshop gabs schöne Messungen[2]. Nilfs2 ist ein log-structured-FS welches sich vor allem zum Ziel gesetzt hat seeks zu vermeiden und alle writes so gut wie möglich sequentiell zu erledigen. Seit 2.6.30 in mainline, fixes und dergl. in 2.6.31. Außerdem bietet es continuous snapshotting in O(1) Aufwand --- also auch sehr interessant am server.

[1]http://www.nilfs.org/en/about_nilfs.html
[2]http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf

ist handelt sich im Moment um ein rein virtuelles Setup.
Also iSCSI Target und Initiator am selben Virtualisierungshost.

Dieses nilfs2 klingt sehr vielversprechend, sequentielle Writes würden bei dieser Hardware ja weniger ein Problem sein.
Danke für den Input!

Zitat von Ringding

Nur so am Rande erwähnt: ich bin auch von der Write-Performance von ZFS auf OpenSolaris ziemlich begeistert...

Kann ich mir gut vorstellen;

Ich kenn die Demos, die Doku, und habs mal in einer KVM instanz (virtio) ausprobiert und fands sehr nice eigentlich. Volume management, multi device und filesystem management in einem sind ein Traum! Schau dir mal den SSD FS performance link aus meinem vorherigem post an, nilfs2 schlägt sogar btrfs um einen absolut beachtenswerten Betrag und btrfs soll ZFS ja wirklich Konkurrenz machen. Sind grad spannende Zeiten für FS, besonders unter Linux.


Netter read ZFS "vs" btrfs: http://lwn.net/Articles/342892/

Warum nicht selbst KVM drauf fahren? Ich bin alles andere als ein Fan von RHEL -- aber ich verstehe den Bedarf nach einem zertifiziertem setup -- RHEL 5.4 soll ein Traum sein was KVM angeht. (Anm.: Verwende einige Server mit KVM hypervisor und allen möglichen guests allerdings auf lenny und jaunty server).

Die HS21 sollen ja sowieso nur von der SAS platte booten und den rest von einem FC o. iSCSI SAN fahren von der Konzeption her -- zumindest verstehe ich alle Blade-Angebote mit nur einem SAS Schacht als genau dafür gedacht. Gerade im Blade-Sektor seh ich eigentlich nur SAN basierte setups.

Ein shared GFS2 mit io fencing und allem drum und dran auf einem sinnvollem RAID10 mit 2x24 disks ist da sicher nicht verkehrt. Und du designst dieses Ding?