Suport pentru fișiere mari

Suportul pentru fișiere mari este o proprietate a sistemelor de operare sau a sistemelor de fișiere pentru a putea deschide și edita fișiere foarte mari. Adesea, sistemul folosit este înainte de această limită, unele versiuni Linux (mai vechi) , acestea sunt ,. B. 2 GiB sau cu FAT32 4 GiB. Bazele de date mari de pe servere, editarea imaginilor sau editarea video, dar necesită adesea fișiere mari (engleză. Fișiere mari ) care sunt semnificativ mai mari, deci nu trebuie să fie afectată o astfel de aplicație de la o limită de dimensiune mică pentru fișiere.

Descriere

Problema cu sistemele de operare pe 32 de biți care sunt răspândite de zeci de ani este restricția de mărime a numerelor întregi . Un întreg pe 32 de biți valorează numai până la 2 GiB (cu semn care reprezintă) sau 4 GiB (fără semn). Pentru a suporta fișiere foarte mari, un nou tip de date și funcțiile sistemului de operare asociate trebuie introduse în programele pe 32 de biți , ceea ce face necesară rescrierea programelor vechi. Versiunile mai vechi și în special programele care nu mai sunt întreținute pot, prin urmare, prelucra fișiere cu o dimensiune maximă de 2 sau 4 GiB, chiar dacă există suport pentru fișiere mari .

Dezvoltarea unui API cu proprietăți pe 64 de biți a avut loc prin dezvoltarea de hard disk-uri , care a rupt limita de gigabyte la începutul anilor 1990. Ulterior, s-au dezvoltat sisteme de fișiere adaptate acestuia - printre care FreeBSD UFS2 , Linux ext2 (1993) și Windows NTFS (1993). Funcționalitatea kernel-ului sistemului de operare a fost transmisă aplicațiilor în diferite moduri, până când a fost agreat un API comun în mediul Unix la „Summit-ul de fișiere mari” independent de producător din 1996. Acest lucru a fost stabilit cu specificația unică UNIX versiunea 2 (UNIX 98).

Aritmetica din compilatoarele C asociate a fost adăugată ca un nou tip de date pe 64 de biți „lung lung” în C, cu standardizarea pentru C99 (din 1995). Acest lucru a urmat de la dezvoltarea sistemelor de operare pentru arhitecturi pe 32 de biți pentru a utiliza un model de programare ILP32, în care tipurile de date tradiționale „int”, „lung”, „pointer” sunt fiecare pe 32 de biți. Funcțiile tradiționale „ftell” și „fseek” au fost astfel limitate la 32 de biți. Pentru Posix "ftello" / "fseeko" și Windows "_ftelli64" / "_fseeki64", producătorii au introdus un tip de date pe 64 de biți - inițial cu nume diferite.

implementare

Adoptarea API-ului LFS în programele pe 32 de biți a rămas incompletă mult timp. Un studiu din 2002 a arătat că chiar și bibliotecile de bază ale sistemului de operare au fost încă livrate fără suport LFS și, prin urmare, au restricționat indirect numeroase aplicații. Biblioteca zlib utilizată pe scară largă nu a acceptat adăugarea pe 64 de biți pe platformele pe 32 de biți până în 2006.

În zona PC-urilor / stațiilor de lucru, problema a fost în cele din urmă rezolvată deoarece au fost utilizate doar arhitecturi pe 64 de biți . Microsoft Windows Server 2008 a fost ultima versiune de server care a fost livrată pe 32 de biți. Redhat Enterprise Linux 7 a fost furnizat ca sistem de operare pe 64 de biți doar când a fost lansat pentru prima dată în 2014. Ubuntu Linux a oprit livrarea ca sistem de operare pe 32 de biți în 2019. Nvidia a încetat să dezvolte drivere pe 32 de biți în 2018 și nu a furnizat actualizări din ianuarie 2019. Mac OS de la Apple a oprit dezvoltarea de 32 de biți în 2018, astfel încât macOS Mojave este disponibil doar ca sistem de operare pe 64 de biți. Cu Microsoft Windows 10 , suportul pe 32 de biți de pe desktop va fi menținut până în 2025, deoarece la începutul anului 2020 a înlocuit doar ultimele versiuni vechi (Windows 7, Windows 8), dintre care unele erau încă utilizate pe arhitecturi i386. Cu toate acestea, Microsoft Windows 11 a fost furnizat doar ca sistem de operare pe 64 de biți de la lansarea inițială în 2021.

În domeniul dispozitivelor mobile, Google solicită asistență nativă pentru aplicații pe 64 de biți de către aplicații din august 2019, astfel încât suportul pe 32 de biți din Android este întrerupt . Trecerea la 64 de biți a început în 2014, când toate procesoarele mai noi au fost anunțate doar în 64 de biți și un sistem de operare adecvat a fost pus la dispoziție anul acesta cu Android 5 („Lollipop”). Apple a început deja tranziția cu Apple A7 pe 64 de biți , care a fost prezentat în 2013. Din 2015, Google a livrat stația de lucru pentru dezvoltatori sub Linux doar pe 64 de biți. În mai 2019, prevalența versiunilor Android sub 5 era încă de aproximativ zece procente. Pentru Google Play App Store , s-a stipulat că din august 2019 trebuie furnizate întotdeauna versiuni pe 64 de biți ale aplicațiilor, cu excepția jocurilor pentru care se aplică această cerință din august 2021. Întrucât dezvoltatorii de aplicații se concentrează pe o singură compilație , mulți producători au stabilit versiunea 5 ca versiune minimă de la mijlocul anului 2019, de exemplu Niantic. O versiune pe 32 de biți era atunci dificil de obținut. Versiunile pre-lansare ale Android 12 din 2020 nu mai oferea un emulator pe 32 de biți pentru dezvoltatori. Android 12 va fi lansat în septembrie 2021, cota de piață a versiunilor Android până la versiunea 4 scăzând sub 2% până în aprilie 2021.

Cu excepția platformelor încorporate cu programele lor specializate, atenția asupra suportului pentru fișiere mari din codul programului va scădea din 2020.

Probleme conexe

Problema din anul 2038 arată în special că reprezentarea tradițională a mărcilor temporale ca „lungă” pe 32 de biți poate duce la probleme. Acestea se vor depăși reciproc și cu trecerea la sisteme pure pe 64 de biți. Între timp, o ștampilă pe 64 de biți a fost disponibilă și pe sistemele pe 32 de biți. În API-ul Win32, acest lucru însemna că noilor funcții cu ștampile de timp pe 64 de biți li s-a dat sufixul „64”, iar lungimile fișierului pe 64 de biți au fost marcate cu un sufix anexat „i64” - cu siguranță în toate cele patru combinații (findfirst32, findfirst64, findfirst32i64, findfirst64i32). API UNIX98, pe de altă parte, introduce funcții suplimentare cu sufixul "64" cu "_LARGEFILE64_SOURCE".

Contoare de blocuri pentru dispozitive de stocare în masă sunt legate de API-ul de fișiere mari. Datorită dimensiunii obișnuite a blocurilor de date de 512 octeți, numerele de 32 de biți au fost limitate doar ulterior. Când hard disk-urile au atins dimensiunea de 2 terabytes (în jurul anului 2010), înregistrarea master boot a trebuit să fie înlocuită ca tabel de partiții de tabela de partiții GUID , care apoi a definit contoare pe 64 de biți pentru LBA ( adresa blocului liniar ). Contoare inode utilizate în sistemele Unix , de asemenea, a trebuit să fie extinse, la fel ca alte contoare de fișiere (de exemplu, cu funcțiile stat64 / setrlimit64). Revizuirea kernel-ului Linux la versiunea 2.4 a avut loc în jurul anului 2001, împreună cu introducerea suportului LFS, care a fost apoi preluat de glibc. Deoarece schimbarea a avut loc în același timp, odată cu activarea LFS pe 64 de biți în arhitecturi pe 32 de biți din biblioteca GNU-C pentru Linux, contoare de blocuri inode și funcțiile conexe sunt, de asemenea, schimbate pe 64 de biți.

Sistemul de fișiere ext3 din 2001 a preluat apoi câteva valori pe 64 de biți în driver, dar a rămas limitat la contoare de blocuri pe 32 de biți pe dispozitivul de stocare în masă. Deoarece lucrați în cea mai mare parte în formatul avansat de blocuri de 4 kilobyte, maximul aici este de obicei 8 sau 16 terabytes. Dispozitivele de stocare în masă mai mari, în intervalul a zeci de terabyți, trebuiau apoi formatate cu XFS , care acceptă, de asemenea, inodii pe 64 de biți în formatul de date și, astfel, pătrund în gama exabyte. Primele 16 hard disk-uri terabyte au fost livrate de la mijlocul anului 2019. Ca unitate SSD , dispozitivele de stocare în masă cu 32 TiB erau deja disponibile din 2016 și au fost anunțate pentru 2020 dincolo de 100 TiB.

Vezi si

  • RF64 ca extensie pe 64 de biți a fișierelor audio RIFF WAVE
  • FAT32 + ca extensie compatibilă cu sistemul de fișiere FAT (până la 256 GiB)
  • ext4 ca extensie pe 48 de biți a sistemului de fișiere ext3 (> 16 TiB din versiunea 1.42 e2fsprogs)

Link-uri web

Dovezi individuale

  1. ^ Adăugarea suportului pentru fișiere mari la specificația unică UNIX® . Grupul Deschis. 14 august 1996.
  2. ↑ http://ac-archive.sourceforge.net/largefile/distros.html
  3. ↑ https://www.zlib.net/ChangeLog.txt
  4. ↑ Panagiotis Kolokythas: Windows Server 2008: ultimul sistem de operare Microsoft pe 32 de biți pentru servere . Lumea computerelor. 28 mai 2007.
  5. ↑ Aplicațiile pe 32 de biți sunt acceptate în versiunile RHEL 7 sau versiuni ulterioare? . Palarie rosie. Februarie 2014.
  6. ↑ Will Cooke: pachete Intel pe 32 de biți pe Ubuntu începând cu ora 19.10 . Canonic. 2 iunie 2019.
  7. ↑ Matthew Addams: Nvidia întrerupe suportul pentru platformele Windows pe 32 de biți . Raport Windows. 12 aprilie 2018.
  8. ↑ Steven Silver: Mojave este ultima versiune Apple de macOS pentru a sprijini aplicații pe 32 de biți . Apple Insider. 5 iunie 2018.
  9. ↑ Asistența pentru Windows 7 se încheie pe 14 ianuarie 2020 . Microsoft. Adus pe 9 februarie 2020.
  10. ↑ Florian Müssig: Cerințe de sistem pentru Windows 11: Când o face, ce poate eșua . Fierbinte. 25 iunie 2021.
  11. ↑ Andreas Sebayang: Pe drumul către aplicații Android pe 64 de biți . Golem. 17 ianuarie 2019.
  12. ↑ a b mw: Google anunță sfârșitul aplicațiilor Android pe 32 de biți în 2021 . Revista IT. 17 ianuarie 2019.
  13. ↑ Android pe 64 de biți: aceste procesoare sunt acolo, aceste schimbări vin . Utilizator Android. 26 august 2014.
  14. ↑ Platform-tools 23.1.0 Linux s-a schimbat pe 64 de biți fără notificare prealabilă. . Android Public Tracker. 11 decembrie 2015.: „Se pare că conținutul android-sdk-linux / platform-tools este ELF pe 32 de biți în 23.0.1, dar ELF pe 64 de biți în 23.1_rc1 și 23.1.0. [..] Am setat ANDROID_EMULATOR_FORCE_32BIT = true [..] 23.0.1 este ultima versiune Linux pe 32 de biți. "
  15. ↑ F. Tenzer: Proporția diferitelor versiuni Android pe toate dispozitivele cu sistem de operare Android la nivel mondial în perioada 1 mai - 7 mai 2019 . Statista. 14 noiembrie 2019.
  16. ↑ Google anunță sfârșitul aplicațiilor Android pe 32 de biți în 2021 . Revista IT. 17 ianuarie 2019.
  17. ↑ Elia Del Favero: Ingress și Pokémon Go vor avea în curând nevoie de cel puțin Android 5 . 10 iunie 2019.
  18. ↑ De ce versiunea 32b 0.159.0 apk încă nu este disponibilă? . Reddit TheSilphRoad /. Decembrie 2019.
  19. ↑ Obțineți Android 12 . Google.: „Rețineți că imaginile sistemului de emulator Android pe 32 de biți nu sunt acceptate în Android 12.”
  20. ↑ Distribuirea diferitelor versiuni Android în utilizarea internetului de către dispozitivele cu sistem de operare Android la nivel mondial în aprilie 2021 . Statista. 3 mai 2021.
  21. ↑ Referința funcției CTF găsiți întâi . Microsoft. Adus în 20200210.
  22. ↑ a b c Andreas Jaeger: Suport pentru fișiere mari în Linux . SUSE GmbH. 15 februarie 2015.
  23. ↑ linux / bits / stat.h: / * Notă stat64 are aceeași formă ca stat pentru x86-64. * /
  24. ↑ MJ Rutter: Problema inodului pe 64 de biți . Adus pe 10 februarie 2020.
  25. ↑ a b Ext4 Howto . kernel.org. 11 februarie 2019.: „Deși sistemele de fișiere foarte mari se află pe lista de caracteristici ext4, e2fsprog-urile curente limitează în prezent dimensiunea sistemului de fișiere la 2 ^ 32 blocuri (16TiB pentru un sistem de fișiere bloc 4KiB). Permiterea sistemelor de fișiere mai mari de 16T este una dintre următoarele funcții cu prioritate înaltă de completat pentru ext4. "
  26. ↑ Thomas Scherer: SSD Samsung de 32 TB: Începutul sfârșitului hard disk-ului . Alegător. 15 august 2016.