Поддержка больших файлов ( 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]
Этот переход вызвал проблемы с развертыванием и потребовал внесения изменений в конструкцию, последствия которых можно наблюдать до сих пор:
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]
Оказывается, содержимое 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.
Хотя очень большие файловые системы есть в списке возможностей ext4, текущий e2fsprogs в настоящее время все еще ограничивает размер файловой системы 2^32 блоками (16TiB для файловой системы с блоками 4KiB). Разрешение файловых систем размером более 16T является одной из следующих высокоприоритетных функций, которые необходимо завершить для ext4.