Поддержка больших файлов

Поддержка больших файлов ( LFS ) — термин, часто применяемый к возможности создания файлов размером более 2 или 4  ГиБ в 32-битных файловых системах .

Подробности

Традиционно многие операционные системы и их базовые реализации файловых систем использовали 32-битные целые числа для представления размеров и позиций файлов . Следовательно, ни один файл не мог быть больше 2 32 − 1 байта (4 ГиБ − 1). Во многих реализациях проблема усугублялась обработкой размеров как знаковых чисел, что еще больше снижало предел до 2 31 − 1 байта (2 ГиБ − 1). Файлы, которые были слишком велики для обработки 32-битными операционными системами, стали известны как большие файлы .

Хотя это ограничение было вполне приемлемым во времена, когда жесткие диски были меньше, общее увеличение емкости хранилища в сочетании с возросшим использованием файлов на серверах и настольных компьютерах, особенно для файлов баз данных и мультимедиа , привело к тому, что поставщикам ОС пришлось преодолеть это ограничение.

В 1996 году несколько поставщиков отреагировали формированием отраслевой инициативы, известной как Large File Summit, для поддержки больших файлов в POSIX (в то время Windows NT уже поддерживала большие файлы в NTFS), очевидный бэкроним "LFS". Саммиту было поручено определить стандартизированный способ перехода на 64-битные числа для представления размеров файлов. [1]

Этот переход вызвал проблемы с развертыванием и потребовал внесения изменений в конструкцию, последствия которых можно наблюдать до сих пор:

  • Изменение размеров файлов на 64-битные часто требовало несовместимых изменений в структуре файловой системы, что означало, что поддержка больших файлов иногда требовала изменения файловой системы. Например, файловая система FAT32 не поддерживает файлы размером более 4 ГиБ−1 (а старые приложения даже только 2 ГиБ−1); вариант FAT32+ поддерживает файлы большего размера (до 256 ГиБ−1), но (пока) поддерживается только в некоторых версиях DR-DOS , [2] [3], поэтому пользователям Microsoft Windows приходится использовать вместо этого NTFS или exFAT .
  • Для поддержки двоичной совместимости со старыми приложениями интерфейсы операционной системы должны были сохранить использование 32-битных размеров файлов, а новые интерфейсы должны были быть разработаны специально для поддержки больших файлов.
  • Для поддержки написания переносимого кода, использующего LFS там, где это возможно, авторы стандартной библиотеки C разработали механизмы, которые в зависимости от констант препроцессора прозрачно переопределяют функции в функции, поддерживающие 64-битные большие файлы.
  • Многие старые интерфейсы, особенно основанные на C , явно указывали типы аргументов таким образом, что не допускали прямого или прозрачного перехода к 64-битным типам. Например, функции C fseekи ftellработают с файловыми позициями типа long int, который обычно имеет ширину 32 бита на 32-битных платформах и не может быть увеличен без ущерба для обратной совместимости. (Это было решено путем введения новых функций fseekoи ftelloв POSIX . [4] На машинах Windows под Visual C++ используются функции _fseeki64и .)_ftelli64

Принятие

Использование API больших файлов в 32-битных программах долгое время было неполным. Анализ показал в 2002 году, что многие базовые библиотеки операционных систем все еще поставлялись без поддержки больших файлов, что ограничивало приложения, использующие их. [5] Широко используемая библиотека zlib начала поддерживать 64-битные большие файлы на 32-битной платформе не ранее 2006 года. [6]

Проблема постепенно исчезла с полным переходом ПК и рабочих станций на 64-разрядные вычисления . Microsoft Windows Server 2008 была последней серверной версией, поставляемой в 32-разрядной версии. [7] Redhat Enterprise Linux 7 была опубликована в 2014 году только как 64-разрядная операционная система. [8] Ubuntu Linux прекратила поставлять 32-разрядный вариант в 2019 году. [9] Nvidia прекратила разработку 32-разрядных драйверов в 2018 году и выпускать обновления после января 2019 года. [10] Apple прекратила разработку 32-разрядных версий Mac OS в 2018 году, выпуская macOS Mojave только как 64-разрядную операционную систему. [11] Окончание жизненного цикла Windows 10 было установлено на 2025 год для настольных компьютеров, что связано с последними обновлениями старых систем, таких как Windows 7 и Windows 8, в январе 2020 года, поскольку некоторые из этих систем работали на старых компьютерах, построенных на архитектуре i386. [12] Однако Windows 11 будет поставляться только как 64-разрядная операционная система с момента выхода первой версии в 2021 году.

Аналогичное развитие событий можно увидеть в мобильной области. Google потребовала поддерживать 64-битные версии приложений в своем магазине приложений к августу 2019 года, [13] что позволяет прекратить поддержку 32-битных версий для Android позже. [14] Переход к 64-битной архитектуре начался в 2014 году, когда все новые процессоры были разработаны для 64-битной архитектуры, и в том же году был опубликован Android 5 («Lollipop»), предоставляющий подходящий 64-битный вариант операционной системы. [15] [14] Apple сделала сдвиг за год до начала производства 64-битного Apple A7 к 2013 году. Google начала поставлять среду разработки для Linux только в 64-битной версии к 2015 году. [16] В мае 2019 года доля версий Android ниже 5 упала до десяти процентов. [17] Поскольку разработчики приложений сосредоточились на одном варианте компиляции , многие производители начали требовать Android 5 в качестве минимальной версии к середине 2019 года, например Niantic. [18] Впоследствии 32-битные версии стало трудно достать. [19]

За исключением встроенных систем с их специальными программами, учет различной поддержки больших файлов станет устаревшим в программном коде после 2020 года.

Проблема 2038 года хорошо известна по другому случаю, когда 32-битный "long" на 32-битных платформах приведет к проблемам. Так же, как и ограничение больших файлов, оно устареет, когда системы перейдут только на 64-битную архитектуру. Тем временем была введена 64-битная временная метка. В Win32 API это видно в функциях, имеющих суффикс "64" наряду с более ранним суффиксом "32". Когда поддержка больших файлов была добавлена ​​в Win32 API, это привело к тому, что функции получили дополнительный суффикс "i64", что иногда приводит к четырем комбинациям (findfirst32, findfirst64, findfirst32i64, findfirst64i32). [20] Для сравнения, UNIX98 API вводит функции с суффиксом "64", когда используется "_LARGEFILE64_SOURCE".

В связи с API больших файлов существует ограничение на количество блоков для носителей большой емкости . При общем размере блока данных 512 байт барьер, вызванный 32-битными числами, возник позже. Когда жесткие диски достигли размера 2 терабайта (около 2010 года), основную загрузочную запись пришлось заменить таблицей разделов GUID , которая использует 64-битные числа для номеров LBA ( логический адрес блока ). В операционных системах типа Unix также потребовалось увеличить номера инодов , которые используются в некоторых функциях (stat64, setrlimit64). Ядро Linux представило это в 2001 году, что привело к версии 2.4, которая была подхвачена glibc в том же году. [21] Поскольку поддержка больших файлов и поддержка больших дисков были введены одновременно, библиотека GNU C экспортирует 64-битные структуры инодов на 32-битных архитектурах одновременно с активацией API LFS Unix в программном коде. [22]

Когда ядро ​​перешло на 64-битные inode, файловая система ext3 использовала их внутри драйвера к 2001 году. Однако формат inode на самом носителе данных застрял на 32-битных числах. [21] Поскольку устройства хранения данных перешли на расширенный формат с 4 килобайтами на блок, фактический предел этого формата файловой системы составляет 8 или 16 терабайт. [21] Обработка больших разделов диска требует использования другой файловой системы, такой как XFS , которая изначально была разработана с 64-битными inode, что позволяло использовать файлы и разделы размером в экзабайт. [23] [24] Первые 16-терабайтные магнитные диски были выпущены к середине 2019 года. Твердотельные накопители с 32 ТиБ для центров обработки данных были доступны еще в 2016 году, а некоторые производители прогнозировали выпуск SSD на 100 ТиБ к 2020 году. [25]

Смотрите также

Ссылки

  1. ^ Solaris OS group (март 1996 г.). "Большие файлы в Solaris: Белая книга" (PDF) . Sun Microsystems . Архивировано из оригинала (PDF) 28.02.2007.
  2. ^ Kuhnt, Udo; Georgiev, Luchezar I.; Davis, Jeremy (2007). "FAT+ draft revision 2" (2-е изд.). Архивировано из оригинала (FATPLUS.TXT) 2015-02-19 . Получено 2015-08-05 .
  3. ^ Kuhnt, Udo (2011-07-21). "DR-DOS/OpenDOS Enhancement Project". Архивировано из оригинала 2016-06-04 . Получено 2015-04-20 .
  4. ^ "Добавление поддержки больших файлов в единую спецификацию UNIX". Рабочая группа X/Open Base. 1996-08-14 . Получено 2006-09-10 .
  5. ^ "Distro Makers". 2002-01-13.
  6. ^ https://www.zlib.net/ChangeLog.txt [ простой текстовый файл URL ]
  7. ^ Колокитас, Панайотис (28 мая 2007 г.). «Windows Server 2008: Microsoft предлагает 32-битную систему для сервера» (на немецком языке). ПК Велт .
  8. ^ «Поддерживаются ли 32-битные приложения в RHEL 7 или более поздних версиях?». Red Hat . Февраль 2014 г.
  9. ^ Кук, Уилл (2019-06-02). «32-битные пакеты Intel в Ubuntu с 19.10 и далее». Canonical.
  10. ^ Аддамс, Мэтью (2018-04-12). «Nvidia прекращает поддержку 32-битных платформ Windows». Windows Report.
  11. ^ Сильвер, Стивен (2018-06-05). «Mojave — последняя версия macOS от Apple, поддерживающая 32-битные приложения». Apple Insider .
  12. ^ «Поддержка Windows 7 закончилась 14 января 2020 г.» (на немецком языке). Майкрософт . Проверено 9 февраля 2020 г.
  13. ^ Себаян, Андреас (17 января 2019 г.). «Auf dem Weg zu Reinen 64-битные приложения для Android» (на немецком языке). Голем.
  14. ^ ab mw (17 января 2019 г.). «Google завершит работу над 32-битными приложениями для Android в 2021 году» (на немецком языке). Журнал ИТ.
  15. ^ «64-битный Android: Diese Prozessoren gibt es, diese Veränderungen kommen» (на немецком языке). Пользователь Андроид. 26 августа 2014 г.
  16. ^ "Platform-tools 23.1.0 Linux изменен на 64-бит без уведомления". Android Public Tracker. 2015-12-11. Оказывается, содержимое android-sdk-linux/platform-tools представляет собой 32-битный ELF в 23.0.1, но 64-битный ELF в 23.1_rc1 и 23.1.0. […] Я установил ANDROID_EMULATOR_FORCE_32BIT=true […] 23.0.1 — последняя 32-битная сборка Linux.
  17. ^ Тензер, Ф. (14 ноября 2019 г.). «Anteile der verschiedenen Android-Versionen an allen Geräten mit Android OS weltweit im Zeitraum 01. bis 07. Mai 2019» (на немецком языке). Статистика.
  18. ^ Дель Фаверо, Элия (10 июня 2019 г.). «Ingress und Pokémon Go для Android 5».
  19. ^ «Почему 32-битная версия 0.159.0 apk все еще недоступна?». TheSilphRoad/ . Reddit. Декабрь 2019 г.
  20. ^ "Справочник по библиотеке времени выполнения C (CRT): findfirst". Microsoft . Получено 2020-02-17 .
  21. ^ abc Jaeger, Andreas (2015-02-15). "Поддержка больших файлов в Linux". SuSE GmbH .
  22. ^ linux/bits/stat.h: /* Обратите внимание, что stat64 имеет ту же форму, что и stat для x86-64. */
  23. ^ Раттер, М.Дж. "Проблема 64-битного inode" . Получено 10.02.2020 .
  24. ^ "Ext4 Howto". kernel.org . 2019-02-11. Хотя очень большие файловые системы есть в списке возможностей ext4, текущий e2fsprogs в настоящее время все еще ограничивает размер файловой системы 2^32 блоками (16TiB для файловой системы с блоками 4KiB). Разрешение файловых систем размером более 16T является одной из следующих высокоприоритетных функций, которые необходимо завершить для ext4.
  25. ^ Шерер, Томас (15 августа 2016 г.). «Samsungs 32-TB-SSD: Der Anfang vom Ende der Festplatte» (на немецком языке). Электор .
  • Jaeger, Andreas (15.02.2005). "Поддержка больших файлов в Linux". SuSE GmbH . Получено 10.09.2006 .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Large-file_support&oldid=1217185767"