ReiserFS traagheid. Terug naar Ext3?

[jep]

Heren, dames.

Wij gebruiken het volgende backup platform:

Processor: Intel(R) Xeon(TM) CPU 2.80GHz
RAID bus controller: Areca Technology Corp. ARC-1120 8-Port PCI-X to SATA RAID Controller
Geheugen: 1024MB

Disks: 4 x 400 Gig WD in RAID-5

Filesystem: Reiserfs (3)

Dit alles werkt, maar de snelheid is ver beneden ieder niveau. We backupps losse files (heel veel files) en het plaatsen en vooral verwijderen van deze files kost enorm veel tijd. Tevens is de machine bij het verwijderen van een paar mappen met html files enorm traag.

Ik krijg ook deze fouten in dmesg:

ReiserFS: warning: is_tree_node: node level 8765 does not match to the expected one 1
ReiserFS: sda3: warning: vs-5150: search_by_key: invalid format found in block 70090775. Fsck?
ReiserFS: sda3: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [2619148 2634690 0x0 SD]

Ook na Fsck komen deze meldingen altijd weer terug. Gelukkig is de integriteit van de bestanden helemaal in orde; het is alleen enorm traag.

Nu ben ik gaan googlen en kwam ik erachter dat heel veel mensen ReiserFS als heel erg traag ervaren, vooral op grote volumes zoals deze en tevens bij veel files en deleten.

Wat adviseren jullie om te doen? Ik heb gelezen dat het niet doenlijk is om je reiserfs systeem weer naar ext3 terug te converteren. Of kan dit toch? Of doe ik iets helemaal verkeerd?

[Creepy]

Je FS converteren tussen Ext3 en Reiser kan inderdaad niet, tenzij je een extra partitie aan kan maken waar je de files naartoe kan kopieren (of een extra disk kan gebruiken).

Reiser3 is gewoon traag met verwijderen. Dat is helaas gewoon zo. Ext3 is daar gewoon veel sneller in. Reiser4 schijnt dit soort problemen op te lossen maar een conversie van R3 naar R4 is ook niet zomaar mogelijk.

Als je regalmatig veel files verwijdert, of veel grote files gebruikt gebruik dan geen ReiserFS. ReiserFS is erg snel met veel kleine files (ideaal voor Maildir etc.). maar anders is Ext3 minstens net zo snel of zelfs sneller.

Overigens lijkt een I/O error me niet echt gezond klinken. De disks zelfs zijn 100% goed??

[ Voor 7% gewijzigd door Creepy op 18-08-2006 14:54 ]

[jep]

Yep, dat waren maxtors met dit probleem en zijn nu western digitals met exact hetzelfde. Fsck werkt een uurtje, tot ze weer in gebruik zijn.

Misschien mijn Areca ook maar eens door laten meten. Al had ik dit met Ext3 niet..

[Verwijderd]

Overigens is het werken met veel kleine files ten alle tijden traag, ongeacht filesystem, door de overhead die je dan krijgt bij het openen/seeken/sluiten van een bestand.

[zomertje]

Verwijderd schreef op zondag 20 augustus 2006 @ 18:42:
Overigens is het werken met veel kleine files ten alle tijden traag, ongeacht filesystem, door de overhead die je dan krijgt bij het openen/seeken/sluiten van een bestand.

Mee eens, omdat ik nog wel eens een paar grote files en soms een enorme berg kleine moet verplaatsen/copieren/verwijderen. Ook op een scsi AIX machine merk ik duidelijk een verschil en weten we de schijven goed bezig te houden

[jep]

Zijn daar uberhaupt geen oplossingen voor? Op zo'n machine zijn veel kleine files onvermijdelijk.

[Boudewijn]

nee niet echt.
komt doordat je relatief veel gaat fragmenteren.

Sowieso is kleine bestanden niet slim:
1: je vult niet al je blocks netjes.
2: inode-verspilling

[jep]

Dat kan zijn, maar files inpakken in huge ass archives is in onze situatie nog veel onhandiger dan de traagheid van het systeem.

Ik kan nu namelijk *wel* snel files restoren als die stuk zijn (zonder iets uit te hoeven pakken) plus dat ik bij een servercrash ook razend snel ben.

En... we werken met rsync en hardlinks. De perfecte backup combi. Het werkt alleen wel met losse files.

Ieder voordeel heeft z'n nadeel.

Toch ga ik Ext3 maar even proberen. Klanten die hun eigen backup machine hebben gaan veel sneller dan onze eigen server. Dus dat moet niet mogen.