Kommentarer
- Filsystemer endres … kjerneplanleggere endres … lagring i seg selv endres. Ulike applikasjoner har forskjellige krav. Alt avhenger av for mange variabler å telle, og ytelse er ikke alt – du må også kunne stole på det og vite hvordan du skal håndtere det når ting går sørover. Til slutt må du kjøre dine egne referanser, og ta ditt eget valg …
- Alt du har sagt er konsekvent, det er ingen motsetninger. Du må imidlertid teste for arbeidsbelastningen din. Optimaliseringsantakelser reduserer ofte et system. Mål alltid.
- EXT4 bruker også en viss mengde plass til inoder sammenlignet med XFS. Og som frostschutz sa … alt endrer seg i tid. Da BTRFS kom på markedet, skulle det være en fantastisk FS, men det ser ut til at ting endret seg
- Jeg ' har bare sett god ytelse fra XFS, både i referanser og i praksis. Jeg tviler på at det finnes referanser som viser noe annet (for nyere versjoner av XFS). Spesialiserte filsystemer kan slå XFS for spesialiserte oppgaver, men XFS skal ha ytelse som er sammenlignbar med de andre performante filsystemene.
Svar
En tidligere XFS Q / A nevnte denne siden: Hvordan velge Red Hat Enterprise Linux-filsystem . Jeg tror det vil ta opp spørsmålet ditt om ytelse :-). Dette er fra den offisielle Red Hat kunnskapsbasen. Det ville være upassende å kopiere hele siden. Her er en smak:
En annen måte å karakterisere dette på er at Ext4-filsystemvariantene har en tendens til å prestere bedre på systemer som har begrenset I / O-evne. Ext3 og Ext4 fungerer bedre på begrenset båndbredde (< 200MB / s) og opptil ~ 1000 IOPS-funksjoner. For alt med høyere kapasitet, har XFS en tendens til å være raskere. XFS bruker også omtrent dobbelt så mye CPU-per-metadata-operasjonen sammenlignet med Ext3 og Ext4, så hvis du har en CPU-bundet arbeidsbelastning med liten samtidighet, vil Ext3- eller Ext4-variantene være raskere. Generelt sett er Ext3 eller Ext4 bedre hvis et program bruker en enkelt lese- / skrivetråd og små filer, mens XFS skinner når et program bruker flere lese- / skrivetråder og større filer.
Forrige svar
Her er en tidligere versjon av dette svaret. Jeg har tilpasset og utvidet den, for å gi sammenheng og bekrefte kilden ovenfor. Det er ikke viktig lesing.
Det gir ikke mening å unngå XFS for å være gammel . Det er mange likheter mellom XFS og ext2 / ext3 / ext4, inkludert deres lange og aktive levetid.
XFS er det viktigste støttede filsystemet for RedHat Enterprise Linux. Det har gått mye arbeid for å utvikle XFS over tid, spesielt fra RHEL. Det store antallet nye og avanserte funksjoner er høyere i XFS :-). Se f.eks. støtte for «reflink».
«Desktop Linux» -installasjoner – som også er målrettet mot moderne bærbare datamaskiner – bruker fortsatt generelt ext4. ext4 gir et veldig kjent, kjent miljø.
På en gjennomsnittlig stasjonær PC, gjelder ikke fordelene med XFS nødvendigvis. ext4 kan ha fordeler, inkludert ytelsesfordeler. Selv om du tar figurene ovenfor til pålydende, antyder de at XFS kan ha en fordel på raske moderne bærbare datamaskiner!
For øyeblikket er ext4 vedlikeholder ansatt av Google. ext4 brukes i Googles Android OS. Så ext4 brukes i mange telefoner og nettbrett, som har mindre kraftig maskinvare. [1] [2]
Jeg synes også ext4 er praktisk fordi du kan krympe filsystempartisjonene. Dette er potensielt nyttig når du vil administrere plassen som brukes av forskjellige installasjoner på en enkelt disk. XFS har ikke støtte for krymping, bare vekst. (I prinsippet kan dette adresseres innen LVM ved hjelp av «tynn klargjøring». Se Stratis Storage, som bruker XFS sammen med tynn klargjøring. Kanskje vil Stratis i fremtiden ta av, og alle distroer kan installeres i Stratis).
I noen tilfeller er ext4-designen beskrevet som gammel og rotete. XFS klarte tydeligvis litt bedre her: Enkel filkopi (eller skriv) forårsaker ti sekunders + forsinkelse på Linux-filsystem . OPPDATERING: Denne lenken nevner nå oppdateringer som er sendt inn for å forbedre ext4 her, sannsynligvis for v5. 3 av Linux-kjernen. Og det kan fortsatt være betydelige forbedringer i fremtiden.
XFS «liten filytelse»
XFS-ytelse når det gjelder mange små filer var opprinnelig en stor svakhet, i forhold til andre filsystemer. Forbedringer har blitt gjort over tid.
En stor endring å være oppmerksom på er forsinket loggføring, en gang rundt 2010-2012. Dvs. i tilfelle du ser noen sammenligning av ytelse i små filer som forhåndsdaterer denne funksjonen, er de ikke lenger relevante. Den forsinkede loggingsdesignen var sterkt basert på ext3-logging :-). Likevel var det fremdeles ytelsesforskjeller mellom de to i forskjellige tilfeller. Se: https://lwn.net/Articles/476263/
(Før det ble tilsynelatende «loggformatet versjon 2 lagt til i 2002, noe som bidro til å gjøre metadataytelsen mye bedre». Men dette hjelper sannsynligvis ikke med å svare på dette spørsmålet :-).
Det er noen ytterligere endringer siden den gang. F.eks. Red Hat-dokumentet gjenspeiler kanskje ikke alle de siste endringene. Jeg la merke til dette sitatet:
[…] gratis inode B + trær (finobt) for bedre ytelse på «alderen» filsystemer, og filtyper er nå lagret i katalogen som standard (ftype = 1), noe som i stor grad forbedrer ytelsen i visse scenarier med mange (vanligvis små) filer.
– kommentar Hva er det mest ytelsesrike Linux-filsystemet for lagring av mange små filer (HDD, ikke SSD)?