arrow_back Hvilke begrensninger og problemer finnes med et stort antall filer i en filmappe i Windows og i Linux?

Question

Et arkivdepot kan få inn datauttrekk pakket i DIAS pakkestruktur (tar-fil) med store størrelser som 500 GB eller opp mot 1 TB (eller til og med større?).

Som et eksempel har vi et Noark 5-uttrekk på 500 GB, der storparten av dette er dokumentfilene.
Her er også alle disse filene pakket flatt i en mappe ..\DOKUMENT
Utpakket 291 GB av totalt 477 GB, så er antallet filer 489 155 i denne mappa.

Hvilke begrensninger og problemer finnes med et stort antall filer i en filmappe i Windows og Linux?

Answer 1

Ingen spesifikke begrensninger (for nyere filsystemer) annet an at det tar laaaaaaaaaang tid å vise innholdet i mappa. Enkelte programmer (som eventuelt ikke bruker native explorer for filutlisting) vil også gjerne lese inn hele fillista for mappa ved utføring av jobber etc. og den lista kan dermed ta ganske mye plass i minne ved et stort antall filer med tilhørende path.

Er ofte større problem med path-length i Windows som fra tidligere var begrenset til 260 tegn.

Følgende er begrensninger (snippet fra nettet og ikke kvalitetskontrollert...):
FAT32:
Maximum number of files: 268,173,300
Maximum number of files per directory: 216 - 1 (65,535)
Maximum file size: 2 GiB - 1 without LFS, 4 GiB - 1 with

NTFS:
Maximum number of files: 232 - 1 (4,294,967,295)
Maximum file size
Implementation: 244 - 26 bytes (16 TiB - 64 KiB)
Theoretical: 264 - 26 bytes (16 EiB - 64 KiB)
Maximum volume size
Implementation: 232 - 1 clusters (256 TiB - 64 KiB)
Theoretical: 264 - 1 clusters (1 YiB - 64 KiB)

ext2:
Maximum number of files: 1018
Maximum number of files per directory: ~1.3 × 1020 (performance issues past 10,000)
Maximum file size
16 GiB (block size of 1 KiB)
256 GiB (block size of 2 KiB)
2 TiB (block size of 4 KiB)
2 TiB (block size of 8 KiB)
Maximum volume size
4 TiB (block size of 1 KiB)
8 TiB (block size of 2 KiB)
16 TiB (block size of 4 KiB)
32 TiB (block size of 8 KiB)

ext3:
Maximum number of files: min(volumeSize / 213, numberOfBlocks)
Maximum file size: same as ext2
Maximum volume size: same as ext2

ext4:
Maximum number of files: 232 - 1 (4,294,967,295)
Maximum number of files per directory: unlimited
Maximum file size: 244 - 1 bytes (16 TiB - 1)
Maximum volume size: 248 - 1 bytes (256 TiB - 1)

Answer 2

Jeg kan bidra med et (om noe forenklet) stykke informasjon.

Dette avgjøres gjerne av hvilke funksjonalitet og design filsystemet har - kombinert med diskens lesehastighet. Hvordan filstiene indekserers og hva som lagres av metadata i indeksen er også en avgjørende faktor på ytelsen. Skriving (som i ditt tilfelle ved utpakking) vil være avhengig av hvordan filsystemet håndterer blokkdelegering av rest-data på en fil. Her brukes gjerne suballocation schemes som f.eks. halepakking (tail-packing). En annen ofte glemt faktor er også om diskene er medlem av en pool og om systemet håndterer deduplisering (NO) eller paritet (EN).

Konfigurasjon av blokker
For å forstå hvordan man bør konfigurere disken(ene) når man formatterer den/de må man først forstå hva blokker på en disk er:
En blokk er et indeksert område lagret i en sektor på en disk. I figuren nedenfor kan du se en sektor representert ved bokstaven C. A utgjør et spor, B en geometrisk sektor og D er en klynge (cluster) med sektorer. Tradisjonelt sett har en sektor vært på 512 bytes, men på nyere harddisker er dette i de fleste tilfeller 4096 bytes, altså 4KiB. Du kan se for deg at en blokk er en pappeske som passer inn i ei hylle (sektor).

Det betyr at en blokk i filsystemet bør være konfigurert i ganger med to: 2, 4, 8, 16, 32 osv. for å utnytte diskens hastighet og kapasitet best mulig. Deretter kommer en analyse av filstørrelser som som vil utgjøre majoriteten. Når du skriver en fil til en disk, så vil filsystemet dele opp filen i tilgjengelige blokker og deretter skrive adressene til disse blokkene i filregisteret. Om konfigurert blokkstørrelse er 4KiB, og filen er 10KiB, så vil filen få 3 adresser og ta opp 3 blokker på disken. Den siste halve blokken (eller fil-halen) vil i mange filsystemer være utilgjengelig for andre filer og på mekaniske disker vil blokkene kanskje ligge i forskjellige sektorer, som gjør at lesehastigheten blir forringet over tid (derfor pleier vi å defragmentere/flytte rundt på disse blokkene).

Tail-packing/merging
Noen filsystemer støtter såkalt halepakking og fungerer ved at disse fil-halene blir pakket/spleiset sammen i haleblokker, og derfor får en suballocation i registeret. Du kan se på det som et mini-register i registeret som lagrer adressen til siste rest av en fil i en liten blokk inni en 4KiB blokk, sammen med rest-data fra andre filer.

Dette gir to fordeler: Vi sparer veldig mye plass på disken, fordi alle halene kun tar sin faktiske størrelse istede for en hel blokk. Og det samler flere haler på samme referansested slik at disken ikke trenger å traversere unødvendig mange sektorer for å lese data. Som en bonus har dette den effekten at også operativsystemet kan mellomlagre (page cache) mindre i RAM for bedre ytelse. Denne metoden er derfor svært interessant for mange små filer, sett i sammenheng med de andre faktorene. Vi oppnår både plassbesparelse og ytelse.

Hvordan ordner vi dette?
Et slik oppsett krever ofte litt kunnskap om maskinvare og filsystemer, men jeg anbefaler f.eks btrfs (NO EN) eller min favoritt ZFS (NO EN). Sistnevnte støtter ikke halepakking, men bruker en litt annen metode. Begge har god støtte for NVME og
For å få best mulig utnyttelse av dette, så bør vi samtidig bruke raske harddisker, slik som NVME SSD disker med høy IOPS og rask lese/skrivehastighet.

Oppsummert

• Velg en blokkstørrelse som er best mulig justert etter filstørrelsene du skal lagre (er det flest filer under 4KB, velg 4KB).
• Ikke bruk mekaniske disker i RAID (la filsystemet håndtere dette).
• Du bør bruke disker av typen NVME SSD (f.eks. 1 eller 2) og gjerne via PCI-e fremfor SATA. Lommeboken avgjør.
• Du bør bruke et filsystem som støtter underallokering (suballocation) eller halepakking (tail-packing). f.eks. ZFS, btrfs eller Raiser.
• Du bør bruke linux eller *BSD og kanskje helst en form for SAN/NAS med 10Gbit eller mer mellom server og arbeidsstasjon.
• Ikke aktiver deduplisering i filsystemet.

Selv med disse anbefalingene vil du uansett oppleve noe treghet når vi beveger oss opp i 500+ GB-klassen på tar-filene. Det er uansett andre ting som er mer bekymringsfullt ved så store filer, blant annet at data-råte har enormt potensiale til å ødelegge hele uttrekk. De bør helst være lagret på tape (LTO) i utpakket form, for å sikre mot slike katastrofer. Men det er en helt annen diskusjon.