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

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

Подробности

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

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

В 1996 году несколько поставщиков отреагировали на это, сформировав отраслевую инициативу, известную как Саммит больших файлов для поддержки больших файлов в POSIX (в то время Windows NT уже поддерживала большие файлы в NTFS) очевидное backronym ООО «ЛФС». Перед саммитом была поставлена ​​задача определить стандартизированный способ перехода на 64-битный числа для обозначения размеров файлов.[1]

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

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

Принятие

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

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

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

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

Связанные проблемы

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

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

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

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

Рекомендации

  1. ^ Группа ОС Solaris (март 1996 г.). «Большие файлы в Solaris: Белая книга» (PDF). Sun Microsystems. Архивировано из оригинал (PDF) 28 февраля 2007 г.
  2. ^ «Добавление поддержки больших файлов в единую спецификацию UNIX». X / Open Base Рабочая группа. 1996-08-14. Получено 2006-09-10.
  3. ^ http://ac-archive.sourceforge.net/largefile/distros.html
  4. ^ https://www.zlib.net/ChangeLog.txt
  5. ^ Колокитас, Панайотис (28 мая 2007 г.). "Windows Server 2008: Microsoft Letztes 32-битная система Betrieb для сервера" (на немецком). PC Welt.
  6. ^ «Поддерживаются ли 32-разрядные приложения в RHEL 7 или более поздних версиях?». Красная шляпа. Февраль 2014.
  7. ^ Кук, Уилл (2019-06-02). «32-битные пакеты Intel в Ubuntu начиная с 19.10». Канонический.
  8. ^ Аддамс, Мэтью (2018-04-12). «Nvidia прекращает поддержку 32-битных платформ Windows». Отчет Windows.
  9. ^ Сильвер, Стивен (2018-06-05). «Mojave - последняя версия macOS от Apple для поддержки 32-битных приложений». Apple Insider.
  10. ^ "Поддержка Windows 7 до 14 января 2020 г." (на немецком). Microsoft. Получено 2020-02-09.
  11. ^ Себаянг, Андреас (17.01.2019). "Auf dem Weg zu reinen 64-Bit-Android-Apps" (на немецком). Голем.
  12. ^ а б mw (17 января 2019). "Google kündigt Ende von 32-Bit-Android-Apps per 2021 an" (на немецком). IT Magazin.
  13. ^ "64-битный Android: Diese Prozessoren gibt es, diese Veränderungen kommen" (на немецком). Пользователь Android. 2014-08-26.
  14. ^ «Platform-tools 23.1.0 Linux изменена на 64-битную без уведомления». Общедоступный трекер Android. 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.
  15. ^ Тензер, Ф. (14 ноября 2019 г.). "Anteile der Verschiedenen Android-Versionen an allen Geräten mit Android OS weltweit im Zeitraum 01. bis 07. Mai 2019" (на немецком). Statista.
  16. ^ Дель Фаверо, Элиа (10.06.2019). «Ingress und Pokémon Go - это лысые мыслители Android 5».
  17. ^ "Почему 32-битная версия apk 0.159.0 все еще недоступна?". TheSilphRoad /. Reddit. Декабрь 2019.
  18. ^ "Ссылка на библиотеку времени выполнения C (CRT): findfirst". Microsoft. Получено 2020-02-17.
  19. ^ а б c Джагер, Андреас (2015-02-15). «Поддержка больших файлов в Linux». SuSE GmbH.
  20. ^ linux / bits / stat.h: / * Обратите внимание, что stat64 имеет ту же форму, что и stat для x86-64. * /
  21. ^ Раттер, М. Дж. "Проблема с 64-битным индексным дескриптором". Получено 2020-02-10.
  22. ^ "Ext4 Howto". kernel.org. 2019-02-11. Хотя очень большие файловые системы входят в список функций ext4, текущие e2fsprogs в настоящее время по-прежнему ограничивают размер файловой системы до 2 ^ 32 блоков (16 ТиБ для блочной файловой системы 4 КиБ). Разрешение файловых систем размером более 16T является одной из следующих высокоприоритетных функций, которые необходимо завершить для ext4.
  23. ^ Шерер, Томас (2016-08-15). «SSD Samsung на 32 ТБ: Der Anfang vom Ende der Festplatte» (на немецком). Elektor.
  24. ^ Кунт, Удо; Георгиев, Лучезар I .; Дэвис, Джереми (2007). «FAT + проект редакции 2» (FATPLUS.TXT) (2-е изд.). Получено 2015-08-05.

внешняя ссылка