Støtte for store filer - Large-file support

Storfilstøtte ( LFS ) er begrepet som ofte brukes om muligheten til å lage filer som er større enn enten 2 eller 4  GiB på 32-biters filsystemer .

Detaljer

Tradisjonelt mange operativsystemer og deres underliggende filsystem implementeringer anvendt 32-bits tall som representerer filen størrelser og posisjoner. Derfor kan ingen filer være større enn 2 32 - 1 byte (4 GiB - 1). I mange implementeringer ble problemet forverret ved å behandle størrelsene som signerte tall, noe som ytterligere senket grensen til 2 31 - 1 byte (2 GiB - 1). Filer som var for store til at 32-biters operativsystemer kunne håndtere, ble kjent som store filer .

Selv om grensen var ganske akseptabel i en tid da harddiskene var mindre , førte den generelle økningen i lagringskapasitet kombinert med økt server- og skrivebordsfilbruk, spesielt for database- og multimediefiler , til et sterkt press for OS-leverandører for å overvinne begrensningen.

I 1996 svarte flere leverandører med å danne et bransjeinitiativ kjent som Large File Summit for å støtte store filer på POSIX (på det tidspunktet Windows NT allerede støttet store filer på NTFS), en åpenbar bakramme for "LFS". Toppmøtet fikk i oppgave å definere en standardisert måte å bytte til 64-biters tall for å representere filstørrelser.

Denne bryteren forårsaket distribusjonsproblemer og nødvendige designendringer, og konsekvensene av dem kan fremdeles sees:

  • Endringen til 64-biters filstørrelser krevde ofte inkompatible endringer i filsystemoppsettet, noe som betydde at støtte for store filer noen ganger nødvendiggjorde en endring av filsystemet. For eksempel støtter ikke Microsoft Windows ' FAT32- filsystem filer som er større enn 4 GiB − 1; man må bruke NTFS eller exFAT i stedet.
  • For å støtte binær kompatibilitet med gamle programmer , driftssystemgrensesnitt hadde til å beholde sin anvendelse av 32-bits filer og nye grensesnitt som måtte bli utviklet spesielt for fremstilling i stor fil støtte.
  • For å støtte skriving av bærbar kode som bruker LFS der det er mulig, utviklet C-standardbibliotekforfattere mekanismer som, avhengig av preprosessor- konstanter, omdefinerte funksjonene transparent til 64-biters store filbevisste.
  • Mange gamle grensesnitt, spesielt C- baserte, spesifiserte eksplisitt argumenttyper på en måte som ikke tillot enkel eller gjennomsiktig overgang til 64-bitstyper. For eksempel fungerer C fseekog ftellfungerer på filposisjoner av typen long int, som vanligvis er 32 bits brede på 32-biters plattformer, og kan ikke gjøres større uten å ofre bakoverkompatibilitet. (Dette ble løst ved å introdusere nye funksjoner fseekoog ftelloi POSIX . På Windows-maskiner, under Visual C ++, brukes funksjoner _fseeki64og _ftelli64brukes.)

Adopsjon

Bruk av storfil-API i 32-biters programmer hadde vært ufullstendig i lang tid. En analyse viste i 2002 at mange basebiblioteker for operativsystemer fremdeles ble sendt uten støtte for store filer, noe som begrenser applikasjoner som bruker dem. Det mye brukte zlib- biblioteket begynte å støtte 64-biters store filer på 32-biters plattform ikke før 2006.

Problemet forsvant sakte med PC og arbeidsstasjoner som gikk helt til 64-bit databehandling . Microsoft Windows Server 2008 har vært den siste serverversjonen som ble sendt i 32-bit. Redhat Enterprise Linux 7 ble kun utgitt i 2014 som et 64-biters operativsystem. Ubuntu Linux sluttet å levere en 32-biters variant i 2019. Nvidia sluttet å utvikle 32-biters drivere i 2018, og de sluttet å levere oppdateringer etter januar 2019. Apple sluttet å utvikle 32-biters Mac OS-versjoner i 2018 og leverte macOS Mojave bare som en 64-bit. operativsystem. Den end-of-life for Windows 10 er satt til 2025 på skrivebordet som er relatert til de nyeste oppgraderinger fra gamle systemer som Windows 7 og Windows 8 i januar 2020 som noen av de system kjørte på gamle datamaskiner bygget på i386 arkitektur . Windows 11 leveres imidlertid bare som et 64-biters operativsystem siden den første versjonen i 2021.

En lignende utvikling kan sees i mobilområdet. Google krevde å støtte 64-biters versjoner av applikasjoner i appbutikken sin innen august 2019, noe som gjør det mulig å avbryte 32-biters støtte for Android senere. Skiftet mot 64-bit startet i 2014 da alle nye prosessorer ble designet til en 64-biters arkitektur og Android 5 ("Lollipop") ble publisert det året og ga en passende 64-biters variant av operativsystemet. Apple hadde skiftet året før de begynte å produsere 64-biters Apple A7 innen 2013. Google begynte å levere utviklingsmiljøet for Linux bare i 64-bit innen 2015. I mai 2019 hadde andelen Android-versjoner under 5 falt til ti prosent. Da apputviklere konsentrerer seg om en enkelt kompilasjonsvariant , begynte mange produsenter å kreve Android 5 som minimumsversjon innen midten av 2019, for eksempel Niantic. Deretter var 32-biters versjoner vanskelig å få tak i.

Med unntak av innebygde systemer med deres spesielle programmer, blir hensynet til varierende støtte for store filer foreldet i programkoden etter 2020.

Relaterte problemer

Det år 2038-problemet er godt kjent for en annen sak der en 32-bit "lange" på 32-biters plattformer vil føre til problemer. Akkurat som begrensningen for store filer, blir den foreldet når systemene bare går til 64-bit. I mellomtiden ble det innført en 64-bit tidsstempel. I Win32 API er det synlig i funksjoner som har "64" -suffiks langs det tidligere "32" -suffikset. Når storfilstøtte ble lagt til Win32 API, har det ført til at funksjoner har et ekstra "i64" -suffiks som noen ganger gir fire kombinasjoner. (Findfirst32, findfirst64, findfirst32i64, findfirst64i32). Til sammenligning introduserer UNIX98 API funksjoner med "64" -suffiks når "_LARGEFILE64_SOURCE" brukes.

Relatert til storfil-API er det en begrensning på blokknummer for masselagringsmedier . Med en vanlig størrelse på 512 byte per datablokk, oppstod barrieren som følge av 32-bits tall senere. Når harddiskstasjoner nådde en størrelse på 2 terabyte (rundt 2010), måtte hovedoppstartsposten erstattes av GUID Partition Table som bruker 64-bit for LBA-numrene ( logisk blokkadresse ). På Unix-lignende operativsystemer krevdes det også å forstørre inode- tallene som brukes i noen funksjoner (stat64, setrlimit64). Den Linux-kjernen introdusert som i 2001 førte til versjon 2.4 som ble plukket opp av glibc i det året. Da støtte for stor fil og støtte for stor disk ble introdusert samtidig, eksporterer GNU C-biblioteket 64-biters inodestrukturer på 32-biters arkitekturer samtidig som Unix LFS API aktiveres i programkode.

Da kjernen flyttet til 64-bit inoder, brukte filsystemet ext3 dem internt i driveren innen 2001. Imidlertid satt inode-formatet på selve lagringsmediet fast på 32-biters tall. Da masselagringsenheter flyttet til Advanced Format på 4 kilobyte per blokk, var den faktiske grensen for filsystemformatet 8 eller 16 terabyte. Håndtering av større diskpartisjoner krever bruk av et annet filsystem som XFS, som ble designet med 64-biters inoder fra begynnelsen, slik at du kan bruke exabyte filer og partisjoner. De første 16 terabyte magnetiske diskstasjonene ble levert i midten av 2019. Solid state-stasjon med 32 TiB for datasentre var tilgjengelig allerede i 2016, og noen produsenter spådde 100 TiB SSD innen 2020.

Se også

Referanser

Eksterne linker