Войти
Поддержка больших файлов (LFS ) - это термин, часто применяемый для возможности создавать файлы размером более 2 или 4 ГиБ на 32-битных файловых системах.
Традиционно многие операционные системы и их реализации файловой системы использовали 32-битные целые числа для представления файл размеров и позиций. Следовательно, размер файла не может превышать 2 - 1 байта (4 ГиБ - 1). Во многих реализациях проблема усугублялась из-за того, что размеры рассматривались как числа со знаком, что дополнительно снижало ограничение до 2 - 1 байта (2 ГиБ - 1). Файлы, которые были слишком большими для обработки 32-разрядными операционными системами, стали известны как большие файлы.
Хотя ограничение было вполне приемлемым в то время, когда жесткие диски были меньше, общее увеличение емкости хранилища в сочетании с увеличением использования файлов на сервере и настольном компьютере, особенно для базы данных и мультимедийные файлы, заставили поставщиков ОС преодолеть это ограничение.
В 1996 году несколько поставщиков ответили созданием отраслевой инициативы, известной как Large File Summit, для поддержки больших файлов в POSIX (на тот момент Windows NT уже поддерживала большие файлы в NTFS), очевидный бэкроним "LFS". Саммиту было поручено определить стандартизированный способ перехода на 64-битные числа для представления размеров файлов.
Этот переход вызвал проблемы с развертыванием и потребовал изменений конструкции, последствия которых все еще могут быть замечено:
fseek и ftellработают с позициями в файлах типа long int, которые обычно имеют ширину 32 бита на 32 -битные платформы и не могут быть увеличены без ущерба для обратной совместимости. (Эта проблема была решена путем введения новых функций fseekoи ftelloв POSIX. На компьютерах с Windows в Visual C ++ функции _fseeki64и _ftelli64.)Использование API больших файлов в 32-битных программах долгое время было неполным. Анализ действительно показал, что в 2002 году многие базовые библиотеки операционных систем по-прежнему поставлялись без поддержки больших файлов, что ограничивало приложения, использующие их. Широко используемая библиотека zlib начала поддерживать 64-битные большие файлы на 32-битной платформе не ранее 2006 года.
Проблема постепенно исчезла, когда ПК и рабочие станции полностью перешли на 64-битные вычисления. Microsoft Windows Server 2008 была последней версией сервера, поставляемой в 32-разрядной версии. Redhat Enterprise Linux 7 был опубликован в 2014 году только как 64-разрядная операционная система. Ubuntu Linux прекратил выпуск 32-битного варианта в 2019 году. Nvidia прекратила разработку 32-битных драйверов в 2018 году, и они прекратили выпускать обновления после января 2019 года. Apple прекратила разработку 32-битных версий Mac OS в 2018 году с поставкой macOS Mojave только как 64-битная операционная система. Для Windows 10 на настольных компьютерах не известно об окончании срока службы, что связано с последними обновлениями старых систем, таких как Windows 7 и Windows 8, в январе 2020 года, поскольку некоторые из этих систем работали на старых компьютерах. на архитектуре i386.
Аналогичное развитие наблюдается и в мобильной сфере. Google потребовал поддержки 64-битных версий приложений в своем магазине приложений к августу 2019 года, что позволяет прекратить поддержку 32-битных версий для Android позже. Переход к 64-битной архитектуре начался в 2014 году, когда все новые процессоры были разработаны для 64-битной архитектуры, а в том же году был выпущен Android 5 («Lollipop»), обеспечивающий подходящий 64-битный вариант операционной системы. система. Apple сделала сдвиг за год до начала выпуска 64-битной Apple A7 к 2013 году. Google начала поставлять среду разработки для Linux только в 64-битной версии к 2015 году. В мае 2019 года доля Android версии ниже 5 упали до десяти процентов. Поскольку разработчики app концентрируются на одном варианте компиляции, многие производители начали требовать Android 5 как минимальную версию к середине 2019 года, например Niantic. Впоследствии 32-битные версии было трудно получить.
За исключением встроенных систем с их специальными программами, рассмотрение различной поддержки больших файлов становится устаревшим в программном коде после 2020 года.
Проблема 2038 года хорошо известна по другому случаю, когда 32-битное «длинное» значение на 32-битных платформах приведет к проблемам. Как и ограничение больших файлов, оно устареет, когда системы перейдут только на 64-разрядную версию. Тем временем была введена 64-битная отметка времени. В Win32 API это видно в функциях, имеющих суффикс «64» наряду с более ранним суффиксом «32». Когда к Win32 API была добавлена поддержка больших файлов, это привело к появлению функций, имеющих дополнительный суффикс «i64», который иногда составляет четыре комбинации (findfirst32, findfirst64, findfirst32i64, findfirst64i32). Для сравнения, API UNIX98 представляет функции с суффиксом «64» при использовании «_LARGEFILE64_SOURCE».
В отношении API больших файлов существует ограничение на количество блоков для запоминающего устройства носителя. При обычном размере 512 байт на блок данных барьер, возникающий из-за 32-битных чисел, действительно возник позже. Когда жесткие диски достигли размера 2 терабайта (примерно в 2010 г.), основная загрузочная запись должна была быть заменена на таблицу разделов GUID, которая использует 64-разрядную для номеров LBA (адрес логического блока ). В Unix-подобных операционных системах также требовалось увеличить номера inode, которые используются в некоторых функциях (stat64, setrlimit64). Ядро Linux представило это ядро в 2001 году, что привело к версии 2.4, которую в том же году подхватила glibc. Поскольку поддержка больших файлов и поддержка больших дисков были введены одновременно, GNU C Library экспортирует 64-битные структуры inode на 32-битных архитектурах одновременно с активацией Unix LFS API в программный код.
Когда ядро перешло на 64-битные inode, файловая система ext3 использовала их внутри драйвера к 2001 году. Однако формат inode на самом носителе застрял на 32 -битовые числа. Поскольку запоминающие устройства перешли на расширенный формат с 4 килобайтами на блок, фактический предел этого формата файловой системы составляет 8 или 16 терабайт. Обработка больших разделов диска требует использования другой файловой системы, такой как XFS, которая с самого начала была разработана с 64-битными индексными дескрипторами, что позволяет использовать файлы и разделы эксабайта. Первые магнитные диски емкостью 16 терабайт были поставлены к середине 2019 года. Твердотельные накопители на 32 ТиБ для центров обработки данных были доступны еще в 2016 году, и некоторые производители прогнозировали SSD на 100 ТиБ к 2020 году.
