Linux/Filesystem keuze

[c-nan]

Tot nu toe heb ik op linux systemen altijd gebruik gemaakt van ext2/ext3/ext4, nooit problemen mee gehad. Echter voor een klein project / hobby, ben ik op zoek naar een filesystem welke de beste performance heeft.

- Ongeveer 15.000 bestanden (groeit dagelijks met enkele tientallen)
- 2/3 hiervan is enkele bytes groot, 1/3 is ongeveer 20MB per bestand
- Journaling hoeft niet, data verlies is geen groot issue

De kleine bestanden (~10.000 van enkele bytes) kan ik ook opslaan in een mysql database, maar dat gebeurd nu nog niet.

Welke filesystem past hierbij het beste?

OS is Linux Ubuntu.

[Gomez12]

Wat is het daadwerkelijke probleem wat je met een willekeurig FS tegenkomt?

15.000 is niet echt een wereldaantal.

Ik denk dat je tegen een heleboel limieten / non-performante dingen aan kan lopen, maar FS staat ergens aan het einde (bijv na de hardware waar het FS op draait).
Je keuze voor bijv een dbase zal gigantisch veel meer invloed hebben dan welk FS je kiest ( of je moet ook dingen als Swap-FS / Mem-FS etc mee gaan nemen)

Simpelste oplossing (die ook nog veilig is) : Pomp alles in een dbase en zorg dat de hele dbase in-memory staat en fysiek op een RAID-array met write-back cache staat, dan heb je niets te maken met het FS. Alle FS-transacties gebeuren dan in de achtergrond

[Xudonax]

Met Ext2/3 ben je per bestand minstens 1024 bytes en met standaard instellingen zelfs 4096 bytes kwijt. Hiervoor zou je dus eigenlijk een filesystem willen waarbij dit niet het geval is. Een andere optie is een filesystem met Block suballocation, dit is in ieder geval efficient voor je kleine bestanden.

Filesystems die suballocation ondersteunen zijn Reiser4, JFS en Btrfs. Als ik zou moeten kiezen zou ik voor JFS gaan omdat dit al tijden in de kernel zit.

Voor meer informatie, kijk eens naar Comparison of file systems op Wikipedia.

[c-nan]

Tot zo ver dank voor de reacties. Op het moment loop ik nog niet tegen problemen aan, maar misschien kan het allemaal sneller en efficiënter, en als iets kan, waarom niet gebruiken

Het staat allemaal op een single disk, dus geen RAID. Zoals ik zei, data verlies is niet erg.

Wikipedia artikel had ik inderdaad al gezien, echter loop ik met de meest FS's sowieso niet tegen de limieten aan. Het gaat mij vooral om de performance.

Zal mysql bijvoorbeeld sneller zijn ipv losse bestanden?

[Gomez12]

Memory zal simpelweg sneller zijn dan welk FS dan ook. Oftewel zorg dat het in-memory staat, dat kan bijv met mysql, maar ook met een swapdrive of iets anders.

Je zit te zoeken naar micro-optimalisaties die totaal niet nuttig zijn tov enkele mega-optimalisaties die veel simpeler te halen zijn.

HDD/FS etc zijn per definitie traag

[ Voor 6% gewijzigd door Gomez12 op 11-03-2012 00:02 ]

[H!GHGuY]

Xudonax schreef op zaterdag 10 maart 2012 @ 23:20:
Met Ext2/3 ben je per bestand minstens 1024 bytes en met standaard instellingen zelfs 4096 bytes kwijt. Hiervoor zou je dus eigenlijk een filesystem willen waarbij dit niet het geval is. Een andere optie is een filesystem met Block suballocation, dit is in ieder geval efficient voor je kleine bestanden.

Niet akkoord. Wat de TS wil is inline data. De data van die kleine bestanden wordt in de inode zelf opgeslaan.
Verder moet de TS het FS tweaken:
- een groot aantal inodes
- goeie inode size voor zijn toepassing

Een andere optie is bvb variable block size, zoals XFS het heeft.

Wat soort performance wil de TS trouwens? Is dit een read-mostly disk en wil hij dus vooral snelle read performance, of moet het schrijven snel gaan?

[Verwijderd]

Gomez12 schreef op zondag 11 maart 2012 @ 00:00:
Memory zal simpelweg sneller zijn dan welk FS dan ook. Oftewel zorg dat het in-memory staat, dat kan bijv met mysql, maar ook met een swapdrive of iets anders.

Ik denk niet dat je bestanden in een RDBMS moet proppen voor performance. Een RDBMS is niet gemaakt om snel bestanden te kunnen benaderen. Database drivers streamen blobs vaak ook niet maar houden ze in memory. Dat maakt het geheel onschaalbaar. Persoonlijk stop ik nooit bestanden in een RDBMS en zou ik het iedereen afraden, zeker niet als je praat over bestanden van 20MB; Nooit doen! Het lijkt makkelijk maar het geeft enkel ellende met backuppen, replication, etc. Hiervoor moet je gewoon een bestandssysteem gebruiken.

Met een Swapdrive bedoel je denk ik een ramdisk (zoals tmpfs). Swap is de ruimte die het OS gebruikt als het RAM vol is en een stuk HDD ruimte gebruikt word als geheugen (bagger traag in vergelijking met RAM).

EDIT: Toevallig ben ik nu bezig om uit een legacy applicatie alle BLOB's te pompen naar het bestandssysteem uit PostgreSQL vanwege alle problemen welke we ermee hebben. Het gaat hier om honderdduizenden kleine bestanden varierend van een paar KB tot 10 MB. Deze komen uit eindelijk uit op een SAN met Solaris op een ZFS bestandssysteem.

[ Voor 14% gewijzigd door Verwijderd op 11-03-2012 13:45 ]

[Gomez12]

Verwijderd schreef op zondag 11 maart 2012 @ 13:40:
[...]
Ik denk niet dat je bestanden in een RDBMS moet proppen voor performance.

In theorie heb je gelijk, als je het puur hebt over blobs/binaire data.

Heb je het over data-bestanden dan moet je simpelweg de data in de database stoppen en aangezien de TS al spreekt van de wens om het in een DBMS te stoppen ga ik voor het gemak even uit van data-bestanden...

Verwijderd schreef op zondag 11 maart 2012 @ 13:40:
[...]
Met een Swapdrive bedoel je denk ik een ramdisk (zoals tmpfs). Swap is de ruimte die het OS gebruikt als het RAM vol is en een stuk HDD ruimte gebruikt word als geheugen (bagger traag in vergelijking met RAM).

Yep, ramdisk als je het niet direct in memory gepropt krijgt. Memory (zelfs met een extra slag als bijv ramdisk) outperformed een HDD (/FS) met een factor 1000 oid.

[Ertepeller]

Gomez12 schreef op zondag 11 maart 2012 @ 14:02:
Memory (zelfs met een extra slag als bijv ramdisk) outperformed een HDD (/FS) met een factor 1000 oid.

Maak daar maar miljoen van: hd's werken in de orde van grootte van milliseconden (10 ^-3), bij memory is dat nanoseconden (10 ^-9).

Swap is niet meer dan een veiligheidsmechanisme: op het moment dat het serieus gebruikt gaat worden, zakt de performance als een kaartenhuis in elkaar. Zo gauw je dat ziet (aankomen) moet je naar de winkel rennen om extra RAM-reepjes te gaan halen.
Ik gebruik op mijn laptop ook al jaren geen swap meer, bij 4 GB of meer speelt dat probleem niet. Nooit problemen mee gehad.

[CAPSLOCK2000]

Het is geen populaire keuze maar misschien is reiserfs (versie 3) wel de beste keuze. Dat FS is erg goed in heel veel kleine bestandjes. Kleine bestanden krijgen een aparte behandeling waardoor ze heel snel gelezen kunnen worden. Er wordt nog wel eens getwijfeld aan de betrouwbaarheid maar je schreef zelf al dat dataverlies geen probleem is.

Verder ben ik het met mijn voorgangers eens dat wat extra RAM of een SSD de makkelijkste oplossing is. Bestanden in een database zetten kan snel zijn maar maakt dingen wel complexer. Ik zou het zo lang mogelijk vermijden. (Eigenlijk vind ik het de wereld op z'n kop. Een goed FS zou sneller moeten zijn dan een database als het gaat om het domweg opslaan en terugzoeken van simpele stukken data.)

[Verwijderd]

CAPSLOCK2000 schreef op zondag 11 maart 2012 @ 14:27:
Verder ben ik het met mijn voorgangers eens dat wat extra RAM of een SSD de makkelijkste oplossing is. Bestanden in een database zetten kan snel zijn maar maakt dingen wel complexer. Ik zou het zo lang mogelijk vermijden. (Eigenlijk vind ik het de wereld op z'n kop. Een goed FS zou sneller moeten zijn dan een database als het gaat om het domweg opslaan en terugzoeken van simpele stukken data.)

Ik zou het wellicht zelfs om willen draaien; In het begin is het makkelijk om bestanden in een DB te plaatsen (tijdens applicatie ontwikkeling). Alles kan in een transactie (de informatie over het bestand plus het bestand zelf) zo weet je dat alles altijd consistent is. Daarnaast heb je al infrastructuur om de DB te benaderen in je applicatie zitten. Stel dat je bestanden los op een FS staan (in een spool achtige structuur) en je data over die bestanden in een DB zit dan moet je deze informatie set op de een of andere manier consistent / in sync houden.

HDFS van Apache (Hadoop) kan een optie zijn (alhoewel zeker niet voor de performance enkel voor de schaalbaarheid). Echter moet je bij Hadoop nog wel wat werk verzetten als je veel kleine bestanden (< 64 MB ) hebt want daar bied het out of the box weinig tools voor en is het niet voor gemaakt.

Ik heb zelf welleens een experimentje gedaan met XADrive + PostgreSQL JDBC (XA) + JbossTS wat aardig werkte. Dit is complexer dan bestanden gewoon in de DB proppen maar het werkt ook prima voor bestanden van bijvoorbeeld een paar honderd MB.

[CAPSLOCK2000]

In praktijk heb je gelijk hoor, ik had het meer over het algemene principe. Ik vind het jammer dat onze filesystems nog zo primitief zijn dat we zo vaak databases nodig hebben. Alles wat zich als 'key-value store' gedraagt zou ik liever in het filesystem zelf zien. "Informatie opslaan onder een eenvoudige naam" is precies wat een filesystem doet (of zou moeten doen). Ook metadata hoort daar bij.
Zodra je ingewikkelde queries gaat doen heb je echt een database nodig, maar in praktijk doen de meeste applicaties niks ingewikkelds.