Из Википедии, бесплатной энциклопедии
  (Перенаправлено из поддержки больших файлов )
Перейти к навигации Перейти к поиску

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

Подробности [ править ]

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

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

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

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

  • Переход на 64-битные размеры файлов часто требовал несовместимых изменений макета файловой системы, а это означало, что поддержка больших файлов иногда требовала изменения файловой системы. Например, Microsoft Windows ' FAT32 файловая система не поддерживает файлы размером более 4 ГиБ-1; вместо этого нужно использовать NTFS или exFAT .
  • Чтобы поддерживать двоичную совместимость со старыми приложениями , интерфейсы операционной системы должны были сохранить использование 32-битных размеров файлов, а новые интерфейсы должны были быть разработаны специально для поддержки больших файлов.
  • Для поддержки написания переносимого кода, который использует LFS там, где это возможно, авторы стандартной библиотеки C разработали механизмы, которые, в зависимости от констант препроцессора , прозрачно переопределяли функции на 64-битные функции, поддерживающие большие файлы.
  • Многие старые интерфейсы, особенно основанные на C , явно указывали типы аргументов таким образом, чтобы не допускать прямого или прозрачного перехода к 64-битным типам. Например, C функционирует fseekи ftellработает с позициями в файлах типа long int, который обычно имеет ширину 32 бита на 32-битных платформах и не может быть увеличен без ущерба для обратной совместимости. (Это было решено введением новых функций fseekoи ftelloв 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 году. Google начала поставлять среду разработки для Linux только в 64-битной версии к 2015 году. [14]В мае 2019 года доля версий Android ниже 5 упала до десяти процентов. [15] Поскольку разработчики приложений концентрируются на единственном варианте компиляции , многие производители начали требовать Android 5 в качестве минимальной версии к середине 2019 года, например Niantic. [16] Впоследствии 32-битные версии было трудно достать. [17]

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

Связанные проблемы [ править ]

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

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

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

См. Также [ править ]

  • Ограничение 2 ГБ
  • RF64 - 64-битная поддержка аудиофайлов BWF WAV
  • Сравнение поддержки больших файлов в текстовых редакторах
  • FAT32 + [24]
  • Размер файла
  • Поддержка длинных файлов (LFN)
  • Проблема 2038 года

Ссылки [ править ]

  1. ^ Группа ОС Solaris (март 1996). «Большие файлы в Solaris: Белая книга» (PDF) . Sun Microsystems . Архивировано из оригинального (PDF) 28 февраля 2007 года.
  2. ^ «Добавление поддержки больших файлов в единую спецификацию UNIX» . X / Open Base Рабочая группа. 1996-08-14 . Проверено 10 сентября 2006 .
  3. ^ http://ac-archive.sourceforge.net/largefile/distros.html
  4. ^ https://www.zlib.net/ChangeLog.txt
  5. ^ Kolokythas, Панайотис (2007-05-28). «Windows Server 2008: Microsoft Letztes 32-Bit-Betriebssystem für Server» (на немецком языке). 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. ^ «Der Support für Windows 7 endet am 14. Januar 2020» (на немецком языке). Microsoft . Проверено 9 февраля 2020 .
  11. ^ Sebayang, Andreas (2019-01-17). «Auf dem Weg zu reinen 64-Bit-Android-Apps» (на немецком языке). Голем.
  12. ^ а б мв (17.01.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. ^ Тензер, F. (2019-11-14). "Anteile der verschiedenen Android-Versionen an allen Geräten mit Android OS weltweit im Zeitraum 01. bis 07. Mai 2019" (на немецком языке). Statista.
  16. ^ Дель Фаверо, Элиа (2019-06-10). «Ingress und Pokémon Go выйдут на лысые мысли о Android 5» .
  17. ^ "Почему 32-битная версия apk 0.159.0 все еще недоступна?" . TheSilphRoad / . Reddit. Декабрь 2019.
  18. ^ "Ссылка на библиотеку времени выполнения C (CRT): findfirst" . Microsoft . Проверено 17 февраля 2020 .
  19. ^ a b c Jaeger, Андреас (2015-02-15). «Поддержка больших файлов в Linux» . SuSE GmbH .
  20. ^ linux / bits / stat.h: / * Обратите внимание, что stat64 имеет ту же форму, что и stat для x86-64. * /
  21. ^ Раттер, MJ "Проблема 64-битного inode" . Проверено 10 февраля 2020 .
  22. ^ "Ext4 Howto" . kernel.org . 2019-02-11. Хотя очень большие файловые системы входят в список функций ext4, текущие e2fsprogs в настоящее время по-прежнему ограничивают размер файловой системы до 2 ^ 32 блоков (16 ТиБ для блочной файловой системы 4 КиБ). Разрешение файловых систем размером более 16T - одна из следующих высокоприоритетных функций, которые необходимо завершить для ext4.
  23. ^ Шерер, Томас (2016-08-15). «Samsungs 32-TB-SSD: Der Anfang vom Ende der Festplatte» (на немецком языке). Elektor .
  24. ^ Кунт, Удо; Георгиев, Лучезар I .; Дэвис, Джереми (2007). «FAT + черновик ревизии 2» (FATPLUS.TXT) (2-е изд.) . Проверено 5 августа 2015 .

Внешние ссылки [ править ]

  • Джегер, Андреас (2005-02-15). «Поддержка больших файлов в Linux» . SuSE GmbH . Проверено 10 сентября 2006 .