[linux filesystems] welke voor grote partities?

[usr-local-dick]

Hoi

Ik gebruik nu ext3 voor een partitie van ca. 250 Gb, nu ga ik een raid array maken en dan komt er 1 partitie van ca. 900 Gb.
Hier komen mp3's op te staan dus heel veel files zullen het niet worden.
Heeft het dan nut om iets anders dan ext3 te kiezen?

[Verwijderd]

ext{2|3} heeft nog steeds problemen met grote directories. Persoonlijk denk ik dat je meer aan iets als XFS of ReiserFS(v{3|4}) hebt, waarbij XFS mijn persoonlijke voorkeur zou hebben. Dit omdat het een "bewezen" filesystem is, en het goed kan omgaan met grote files (en mij maak je niet wijs dat je 900gb aan alleen maar mp3's op dat array gaat zetten, daar zullen vast ook wel films oid bijkomen )

[elTigro]

ach, bij ons draait er een machine met 2 TB en die heeft ook gewoon Ext3. niet veel aan te merken ofzo.. De controller zelf is niet zo snel, dus voor de snelheid hoeven we ook niet iets anders..
Als je er af en toe wat mp3-tjes vanaf leest, heb je toch niet veel meer nodig dan ext3 lijkt mij?

[MrBarBarian]

usr-local-dick schreef op vrijdag 19 november 2004 @ 09:24:
Hoi

Ik gebruik nu ext3 voor een partitie van ca. 250 Gb, nu ga ik een raid array maken en dan komt er 1 partitie van ca. 900 Gb.
Hier komen mp3's op te staan dus heel veel files zullen het niet worden.
Heeft het dan nut om iets anders dan ext3 te kiezen?

900gb aan mp3.. en dan niet veel files... gemiddelde grootte van een mp3 is +/- 5 mb.... Volgens mij krijg je redelijk wat files dan hoor..

En ik vraag me af hoe je 900gb vol wil krijgen met mps, maar dat terzijde..

[elTigro]

En ik vraag me af hoe je 900gb vol wil krijgen met mps, maar dat terzijde..

van elk mp3-tje versies maken in 4 verschillende kwaliteiten

[BoAC]

Verwijderd schreef op vrijdag 19 november 2004 @ 09:35:
ext{2|3} heeft nog steeds problemen met grote directories. Persoonlijk denk ik dat je meer aan iets als XFS of ReiserFS(v{3|4}) hebt, waarbij XFS mijn persoonlijke voorkeur zou hebben. Dit omdat het een "bewezen" filesystem is, en het goed kan omgaan met grote files (en mij maak je niet wijs dat je 900gb aan alleen maar mp3's op dat array gaat zetten, daar zullen vast ook wel films oid bijkomen )

Alleen als je dan XFS gebruikt voor veel kleine files raak je veel ruimte kwijt aan 'slack' maar voor de TS zal XFS het beste zijn.

Hoe zit het trouwens met repareren van XFS?
Mijn ervaring met reiserfs icm 100GB is dat het heel lang kan duren +/- halve dag

[usr-local-dick]

900gb aan mp3.. en dan niet veel files... gemiddelde grootte van een mp3 is +/- 5 mb.... Volgens mij krijg je redelijk wat files dan hoor..

En ik vraag me af hoe je 900gb vol wil krijgen met mps, maar dat terzijde..

Nou bij 5 mb per stuk, dat is dus 200 per Gb, dus 900*200= 180.000 bestanden.

Dat is op zich niet veel voor een filesysteem, beetje server heeft ook makkelijk 100.000 bestanden (web/file server dan).

Wat ik me nog wel bedacht, er zal een directory komen met enkele duizenden subdirectories, maakt dat nog wat uit?

En ja 900 gb is groot maar ik wil er nu in 1 keer van af zijn, dat geklooi iedere keer met een extra schijfje hier, schijfje daar. Op het laatst heb je weer een wirwar van mountpointen, super onoverzichtelijk.
Ik heb me erbij neergelegd, er moet nu geld uitgeven worden en dan bouw ik 1 mega volume waar ik voor een paar jaar klaar mee ben.

[DDX]

ik gebruik persoonlijk voor mijn fileserver gewoon ext3
(2TB raid5 met 13 disken)

geen klachten over performance (read 250MB/sec/write 100MB/sec)

(wel even denken aan -i paramater bij aanmaken van filesystem, anders krijg je veel te veel inodes (en heeft fsck paar gb mem nodig om te kunnen draaien)

[DDX]

ik ga trouwens vanmiddag mijn raid opnieuw formateren
ik denk er hard over om nu voor xfs te gaan

wie overtuigt mij om xfs te kiezen/toch bij ext3 te blijven

[Kees]

Ik gebruik bij ons op de fileserver reiserfs. Er staan zo'n 231k bestanden in 23k dirs. Gemiddelde bestandsgrootte ~188kb. Reiserfs werkt prima en snel hiermee.

En tja, het is tegenwoordig een persoonlijke keuze waar je voor gaat
Ik zou in dit geval ext2/3 nemen (ja, ext2/3 is langzamer op kleine files, klein is < 10kb).
XFS heb ik altijd een beetje 'desktop fs' bij

[_JGC_]

Persoonlijk zou ik voor XFS of ReiserFS gaan. Het nadeel van ext2 en ext3 is dat elke zoveel dagen een complete filesystem check komt, wat nogal nadelig is op een grote disk. Ik huiver dus ook bij het idee om bij dit bedrijf waar ik nu werk een drietal servers te rebooten: alle 3 een 36GB partitie met ext2 en een enorm aantal kleine files

Een tijd geleden heb ik bij een bedrijf ext3 naar reiserfs geconverteerd. Er werd geklaagd over enorme wachttijden bij directory listings, waarbij het ging om directories waar ze iets van 1000 excel bestanden van 3-4MB per stuk hebben staan. Na conversie was het al een flink stuk verbeterd.

Een tijdje terug had ik performance problemen met mijn mailserver met Maildir achtige mailfolders (Cyrus heeft behalve maildir ook nog db zut eromheen, maar verder ist gewoon Maildir zoals qmail dat gebruikt). Filesystem was Reiserfs, na conversie naar XFS is het een flink stuk sneller geworden (dat terwijl Reiserfs snel zou moeten zijn bij kleine files, en vooral als je mount met -notail).

Wat kees bedoelt met XFS als desktop OS kan ik me wel indenken: voor een desktop is er zowat geen filesystem sneller dan XFS (misschien reiser4, maar dat moet zich eerst maar eens bewijzen: pas vanaf kernel 2.4.18 was reiserfs pas echt bruikbaar, dus ik verwacht voor 2.6.20 geen stabiele reiser4).

Ik heb ervaring met zowel ext3, XFS, JFS als Reiserfs, en ik denk persoonlijk dat je je aan Reiserfs en XFS geen buil kunt vallen. aangezien MP3s redelijk grote bestanden zijn en geen maildirs met allemaal kleine rotbestandjes erin, denk ik dat het met de slackspace van XFS vergeleken met Reiserfs wel wat mee zal vallen.

[Verwijderd]

http://www-106.ibm.com/de...ml?t=gr,lnxw16=FileSysP11

Hier staat een korte vergelijking van ReiserFS, XFS en ext3. Op onze servers draaien we XFS. Is sneller dan ext3 en we durfden het niet aan om op een productieservers RFS te gaan draaien, gezien het grote aantal problemen die RFS opgeleverd heeft in het verleden.

[ Voor 5% gewijzigd door blaataaps op 28-11-2004 17:55 . Reden: url-tags toegevoegd ]

[DDX]

vandaag flink wat lopen lezen, en denk dat ik voor filesystem nu overga op xfs
't heeft allemaal jaren ok gedraait op ext2, maar ik heb op dit moment even de kans om alles overnieuw te doen (alle data is backuped en ik heb een lege /dev/md0 )
op dit moment loopt een badblock test op dev/md0
(even kijken of de raid 100% ok is)
dus filesystem aanmaken zal morgen worden

ik kwam alleen nog wel even deze opmerking tegen op raid mailinglist :

I use XFS and it is often suggested as a good fs (though I think there may
be some XFS/nfs issues with 2.6 at the moment - see lkml)

nog even uitzoeken wat dat precies voor probleem is, want ik gebruik nfs voor het exporten naar m'n andere linux bakken hier

[Verwijderd]

quote:

Reiser4 was recently released as a stable filesystem.
and if you've been folIowing the news on reiser4.. It's the fastest filesystem on the planet.

/quote

komt van gentoo forum af, draai nu ook rfs op een linux bak. draait goed.
Ik hoorde ook dat rfs niet zo snel corupt raakt als bijvoorbeed ex3, aleen geen idee of dat waar is.

[ Voor 16% gewijzigd door Verwijderd op 29-11-2004 13:33 ]

[DDX]

even waarschuwing :

raid5 in 2.6 kernel is stuk langzamer dan raid5 in 2.4 kernel

even benchmark met 13 disken raid5 :
(verder gelijk systeem alleen booten met 2.4 en 2.6)

code:

2.4.20 : (13d r5 ext3)

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
storage.a2000.nu 2G 21931  99 96429  99 79370  73 28970  99 280316  84 675.7   3
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1444  71 +++++ +++ +++++ +++  2024  99 +++++ +++  5563  98
storage.a2000.nu,2G,21931,99,96429,99,79370,73,28970,99,280316,84,675.7,3,16,1444,71,+++++,+++,+++++,+++,2024,99,+++++,+++,5563,98

2.6.9-ac11 (13d r5 ext3)

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
storage.a2000.nu 2G 21711  99 99906  95 67559  79 24099  92 138763  72 606.4   3
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1470  79 +++++ +++ +++++ +++  1447  78 +++++ +++  4546  96
storage.a2000.nu,2G,21711,99,99906,95,67559,79,24099,92,138763,72,606.4,3,16,1470,79,+++++,+++,+++++,+++,1447,78,+++++,+++,4546,96

heb al contact op raid mailinglist
er mist idd iets in 2.6 kernel
(maar dat zou max 10% performance mogen schelen)

had ook nog even xfs vergelijk gedaan met 2.6 kernel :

alleen dan met 14 disk raid5 :

code:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
storage.a2000.nu 2G 26828  99 123983  73 58525  57 27336  99 171371  96 583.9   4
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1023  12 +++++ +++   920  11  1004  14 +++++ +++   722   9
storage.a2000.nu,2G,26828,99,123983,73,58525,57,27336,99,171371,96,583.9,4,16,1023,12,+++++,+++,920,11,1004,14,+++++,+++,722,9

14d ext3 :

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
storage.a2000.nu 2G 24456  99 109358  89 51669  50 25116  90 132845  69 622.1   4
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1412  77 +++++ +++ +++++ +++  1423  76 +++++ +++  4825  96
storage.a2000.nu,2G,24456,99,109358,89,51669,50,25116,90,132845,69,622.1,4,16,1412,77,+++++,+++,+++++,+++,1423,76,+++++,+++,4825,96

lijkt er dus op dat xfs stukje rapper is
alleen die irritante bug in 2.6 kwa speed dus...

en voor 2.4 is er weer geen LBD support (ook niet via een patch zover ik kan vinden)

[blaataaps]

DDX schreef op dinsdag 30 november 2004 @ 23:08:


alleen die irritante bug in 2.6 kwa speed dus...

Weet je zeker dat het in het raid subsystem zit? Heb je bijvoorbeeld ook getest met een single disk? Het kan bijvoorbeeld ook in de support voor DMA zitten ofzo, in de driver voor je moederbord-chipset. Ik had bijvoorbeeld al bij een upgrade van 2.4.18 naar 2.4.26 (voor xfs zonder extra patch) dat DMA opeens niet meer werkte met identieke config, bleek dat in .26 opeens een extra optie zat voor mijn chipset waardoor DMA niet meer functioneerde. Tis niet te zeggen dat het niet in de raid zit natuurlijk, maar met een simpele check kun je de zoekrichting eventueel beperken

[DDX]

het zit bijna zeker in de raid5 code
disken hangen allemaal op 3ware (2 8 poorts controllers) zijn dus voor linux gewoon scsi disken
single disk doen ze allemaal 50mb/sec (r/w)
en raid0 is ook gewoon snel (220/275 (r/w))

comment van NeilBrown over mijn results :

There is a read optimisation that I haven't implemented in 2.6 yet
that could account for about a 10% difference, but a 30% difference
definitely surprises me.

Normally raid5 will read into the stripe cache, and then copy data out
of the stripe cache and into the request buffer for reads.
The optimisation is to read directly into the request buffer in
situations where no degraded stripes or pending write requests. This
optimisation is implemented in 2.4 and gave me about a 10% speedup on
sequential reads. Its substantially more complicated in 2.6...

I might do a bit of testing myself, but more results from others would
be helpful...

(zijn 30% komt alleen door vergelijk xfs 14 disken met ext2 13 disken, is dus flink wat groter verschil)

maar mocht je nog ideeen hebben wat ik kan testen/doen ?
plan is om morgen uiteindelijk raid aan te maken
en denk dat het toch maar 2.6 wordt
en dan maar hopen dat dit snel gefixt wordt

(2.4 is niet echt optie ivm missen LBD)

[DDX]

heeft er iemand nog tips voor mkfs.xfs ?

code:

]# mkfs.xfs /dev/md0  -f
meta-data=/dev/md0               isize=256    agcount=32, agsize=19230656 blks
         =                       sectsz=512  
data     =                       bsize=4096   blocks=615380864, imaxpct=25
         =                       sunit=64     swidth=896 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=3670016 blocks=0, rtextents=0

kan verder erg weinig docs vinden over tuning oid
(stripe size is 256k / 15 disken)