[linux] Re: veeeel files in 1 directory wissen

[Paul Slootman]

On Sat 21 Mar 2009, Mark van Dijk wrote:
> 
> Ext3 is imho gewoon traag. Ik gebruik reeds jaar en dag jfs op al mijn
> partities: hierbij krijg ik veruit de beste performance. Kan het iedereen

Ik beheer een aantal backup servers, 6 1e-lijns met elk zo'n 2TB aan
data, 2 2e lijns met elk zo'n 20TB aan data. Daarop worden dus
dagelijkse backups op bewaard van zo'n 250 systemen. Dagelijks moeten
dus ook heel veel files verwijderd cq. unlinked worden (het is een
incremental backup systeem gebaseerd op dirvish (wat rsync als
onderliggende laag gebruikt). Onveranderde files worden gelinked vanaf
de backup van de vorige dag, zo kun je heel veel complete dagelijkse
images online hebben zonder dat het zoveel ruimte in beslag neemt (en
geen gedoe met incrementals restoren wanneer je iets terug moet hebben).

Ik heb alle filesystems zo'n beetje geprobeerd (btrfs en ext4 staan op
de nominatie om getest te worden), maar allemaal hebben ze zo hun voor-
en nadelen. Echter, uiteindelijk ben ik toch teruggevallen op het
gebruik van ext3...  Als je die met de juiste opties aanmaakt (zoals al
eerder genoemd), -O dir_index,filetype dan is die ook best wel snel.

Ook de kernel booten met bv. dhash_entries=16777216 ihash_entries=16777216
helpt.

jfs was best wel aardig, maar bij een ongeplande reset moest de
filesystem (8TB toen) eerst een fsck ondergaan die 1,5 uur duurde.
Da's niet waar ik een journalled filesystem voor heb...

xfs is extreem snel met verwijderen van files, althans bij grote files.
Die gebruik ik dus thuis voor m'n NFS share waar m'n dreambox de
opgenomen uitzendingen kwijt kan, want op andere filesystems kan het
weggooien van 4GB toch wel even duren (en zolang hangt de UI van de
dreambox), en met xfs is die direct klaar. Echter, met een heleboel
kleine files is xfs ook niet zo'n held, de metadata updates duren dan
weer lang; relatief langer dan ext3 dus.
Ook heb ik met 2.6.18 ofzo bugs gehad met xfs waardoor de filesystem
soms panickte, en een fsck nodig was. Dat kwam dan nooit 100% meer goed.
Echter met recente kernels lijkt dat wel opgelost te zijn, als die
filesystem dus maar nooit met die foute versie gebruikt is...

reiser3 kan zulke grote filesystems niet aan, valt dus af. Viel ook
tegen qua performance; het is snel als je een bepaalde filenaam weet en
die moet accessen, maar de filesystem aflopen op alle files is
suboptimaal geregeld (die b-trees or whatever die gebruikt worden, zijn
niet optimaal voor het genereren van de complete lijst).

reiser4 heb ik geprobeerd, maar kwam problemen tegen met has collisions
in directories met heel veel files (bij een rm -r geeft ie dan ineens
"can't remove xyz: not found" gevolgd door "can't remove directory abc:
not empty". Er zitten dus nog files in die dir, maar de verwijzingen
zijn weg omdat een andere file met dezelfde hash eerder weggegooid werd.

ext3 is gewoon consequent probleemloos en bug free, en dan is een beetje
minder snel dan een prijs die het mij wel waard is. Niks zo vervelend
als 10TB aan data waar je geen vertrouwen meer in hebt...


Paul Slootman