Файловая система lfs что это

Обновлено: 04.07.2024

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

LFS расширение файла

Тип файла Samsung Phone Params.lfs Format
Разработчик файлов Samsung
Категория файла Системные файлы
Рейтинг популярности файлов

Как открыть файл LFS?

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

Шаг 1. Установите программу, которая поддерживает LFS файлы

Чтобы открыть LFS файл, в системе должна быть установлена соответствующая программа, которая поддерживает этот формат файлов. Ниже представлен список программ, которые поддерживают файлы с расширением LFS.

Программы, открывающие файлы LFS

Android

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

Помните!

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

Шаг 2. Свяжите данное программное обеспечение с файлами LFS

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

Шаг 3. Проверьте, нет ли других ошибок, связанных с файлами LFS

Когда вышеупомянутые решения терпят неудачу, другие варианты должны быть продолжены. Возможно, файл LFS поврежден или поврежден. Наиболее распространенные причины повреждения файла:

Если вставить в привод чистый CD-RW или DVD-RW диск, то проводник Windows 7 автоматически выдаст запрос на форматирование этого диска при попытке открыть этот диск::

LFS это ни что иное как UDF. Файловая система для пакетной записи на CD и DVD диски. Позволяет использовать лазерный диск точно так же как и обычный. То есть копировать и удалять файлы наипростейшим образом. Файловая система UDF в частности используется в DVD-Video.

Mastered это запись диска в файловой системе ISO9660 с расширением Joliet. Файловая система ISO9660 это традиционная файловая система для лазерных дисков. Аудио CD, MP3 диски, диски с компьютерными программами записываются в этой файловой системе.

Использование файловой системы UDF (LFS)

Файловая система UDF используется для пакетной записи на лазерные диски. В зависимости от версии поддерживается разными версиями Windows. Например, Windows XP поддерживает версии 1.50, 2.0, 2.01.

Файловая система UDF также используется в системах записи и воспроизведения видео и аудио, например в DVD плеерах (DVD-video диски изготавливаются с использованием UDF версии 1.50). Есть модели видеокамер, которые записывают снятый материал на DVD-RW диски. Для того, чтобы использовать такой диски вначале его нужно отформатировать.

Вставить в привод чистый CD-RW или DVD-RW диск, то проводник Windows 7 автоматически выдаст запрос на форматирование этого диска при попытке открыть этот диск:

Форматирование в файловой системе может занять прилично времени, например CD-RW 700 mb может форматироваться минут 10 - 12.

После завершения форматирования можно копировать файлы на этот диск прямо через проводник Windows:

Далее нужно открыть диск и на нем выполнить команду «Вставить»:

Однако нужно помнить, что скорость копирования на UDF диск значительно ниже чем на обычный или на USB флеш-диск.

Иван Сухов, 2011 г.

Лог-структурированные файловые системы были введены Rosenblum и Ousterhout в начале 90-х годов для решения следующих проблем.

Растущие системные воспоминания:
С увеличением размера диска объем данных, которые можно кэшировать, также увеличивается. Поскольку чтение обслуживается кешем, производительность файловой системы начинает зависеть исключительно от производительности записи.
Производительность последовательного ввода-вывода превосходит производительность случайного ввода-вывода:
За прошедшие годы пропускная способность доступа к битам с жесткого диска увеличилась, поскольку в одной и той же области можно разместить больше битов. Однако для небольших роторов физически трудно перемещать диск быстрее. Следовательно, последовательный доступ может значительно улучшить производительность диска.
Неэффективность существующих файловых систем:
Существующие файловые системы выполняют большое количество операций записи для создания нового файла, включая записи inode, bitmap и block data и последующие обновления. Короткие поиски и возникающие задержки вращения уменьшают пропускную способность.
Файловые системы не поддерживают RAID:
Кроме того, файловые системы не имеют какого-либо механизма для борьбы с проблемой малой записи в RAID-4 и RAID-5.

Несмотря на то, что скорость процессора и объем основной памяти увеличились в геометрической прогрессии, стоимость доступа к диску развивалась гораздо медленнее. Это требует файловой системы, которая фокусируется на производительности записи, использует последовательную полосу пропускания и эффективно работает как при записи на диск, так и при обновлении метаданных. Именно здесь мотивируется лог-структурированная файловая система (LFS).

Ниже приведены структуры данных, используемые в реализации LFS.

Inodes:
Как и в Unix, inode содержат физические указатели блоков на файлы.
Карта Inode:
В этой таблице указано расположение каждого inode на диске. Карта inode записывается в самом сегменте.
Сегмент Резюме:
Это сохраняет информацию о каждом блоке в сегменте.
Таблица использования сегментов:
Это говорит нам о количестве данных в блоке.

Эффективная последовательная запись на диск:
Однако простой записи последовательно на диск недостаточно для достижения эффективности. Чтобы понять проблему, рассмотрим, что мы записали блок данных D по адресу A0 в момент времени T. Теперь, когда мы получим следующий блок данных в момент времени T + t для записи в A0 + 1, диск уже повернут некоторыми единицы измерения. Если время вращения диска мы должны ждать перед записью второго блока, чтобы два адреса (A0, A0 + 1) были смежными.

и 4 обновления одного и того же файла j, которые записываются на диск сразу. Это один из набора обновлений, буферизированных в LFS. является обновлением файла k, который записывается на диск в следующем обороте.

Процесс в двух словах:
Процесс чтения LFS такой же, как и в файловых системах Unix после нахождения inode для файла (который сохраняется в карте inode). Процесс записи можно обобщить следующим образом:

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

LFS также устраняет вышеупомянутую проблему малой записи в RAID-4 и RAID-5, поскольку целые сегменты записываются вместо небольших блоков данных.

проблемы:
Одна из проблем, которая возникает, состоит в том, что сегменты в журнале имеют тенденцию фрагментироваться, поскольку старые блоки файлов заменяются новыми. Поскольку LFS создает старые копии данных, разбросанных по разным сегментам на диске, их необходимо периодически очищать. Для этого более чистый процесс «очищает» старые сегменты. Этот очиститель берет несколько неполных сегментов и уплотняет их, создавая один полный сегмент, освобождая тем самым пространство.

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

Содержание

Подробности

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

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

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

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

Изменение размеров 64-битных файлов часто требовало несовместимых изменений структуры файловой системы, а это означало, что поддержка больших файлов иногда требовала изменения файловой системы. Например, файловая система Microsoft Windows 'FAT32 не поддерживает файлы размером более 4 ГиБ-1; вместо этого нужно использовать NTFS или exFAT.
Для поддержки двоичной совместимости со старыми приложениями , интерфейсами операционной системы пришлось сохранить использование 32-битных размеров файлов, а новые интерфейсы должны были быть разработаны специально для поддержки больших файлов.
Для поддержки записи переносимого кода, который использует LFS, где это возможно, Стандартная библиотека C авторы разработали механизмы, которые, в зависимости от констант препроцессора , прозрачно переопределяют функции на 64-битные функции, поддерживающие большие файлы.
Многие старые интерфейсы, особенно на основе C , явно указанные типы аргументов таким образом, чтобы не допускать прямого или прозрачного перехода к 64-битным типам. Например, функции C 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 году.

Содержание

Подробности

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

Принятие

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

Читайте также: