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

LiveInternetLiveInternet

—Цитатник

Идеи: из чего можно сделать совушку &.

Декор стены «камнями» Сегодня представляю на ваш суд одну идею, до которой доду.

Каменные баночки. Имитация. Нашла на страницах Страны мастеров нов.

Новый способ изготовления полубусин. Новый способ изготовления полубусин. &nbsp.

—Рубрики

—Музыка

—Поиск по дневнику

—Подписка по e-mail

—Интересы

—Друзья

—Постоянные читатели

—Сообщества

—Статистика

Стирание компакт-диска или DVD-диска

Стирание компакт-диска или DVD-диска

Стирание компакт-диска или DVD-диска

Перезаписываемые компакт-диски (например, диски CD-RW) и DVD-диски (например, DVD-RW, DVD+RW или DVD+RAM) поддерживают многократное стирание и запись содержимого. После стирания содержимого перезаписываемого компакт-диска, DVD-диска или диска Blu-ray можно повторно отформатировать диск и снова записать на него нужные файлы.

Если на компьютере установлено устройство записи компакт-дисков или DVD-дисков, можно скопировать файлы на записываемыйдиск. Этот процесс называется записью диска. В зависимости от выбранного формата диска Windows записывает диски в формате файловой системы LFSили формате Mastered. Дополнительные сведения о выборе формата диска для записи см. в разделе Выбор формата компакт-диска или DVD-диска

fpm_start("true");

В следующих процедурах показано использование проводника для записи диска с данными (тип диска, используемый для хранения, архивирования и обмена файлами между разными компьютерами и устройствами). Если требуется создать другие типы дисков, например видеодиск DVD (для воспроизведения в обычном проигрывателе DVD-дисков) или звуковой компакт-диск (для воспроизведения в обычном проигрывателе компакт-дисков), необходимо воспользоваться другой программой или компонентом Windows.

Запись диска в формате файловой системы LFS

Если нужно записать диск с данными, который будет воспроизводиться на компьютере с Windows XP или более поздней версией, следует выбрать формат файловой системы LFS.

Если диалоговое окно «Автозапуск» не открывается, нажмите кнопку Пуск Если диалоговое окно «Автозапуск» не открывается, нажмите кнопку Пуск Источник

Файловая система с лог-структурой (LFS)

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

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

Хотя все операции чтения невозможно выполнить последовательно (поскольку любой файл может быть доступен в любой момент времени), мы можем использовать эффективность последовательной записи. LFS хранит небольшой буфер всех записей в сегменте памяти. Журнал — это просто структура данных, которая записывается только в начале (можно представить весь диск как журнал). Когда журнал заполнен, он последовательно записывается в неиспользуемую часть диска. Новые данные и метаданные (иноды, каталоги) накапливаются в буферном кеше и записываются одновременно в большие блоки (например, сегменты по 0,5M или 1M).

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

Последовательная запись на диск:
Рассмотрим следующий рисунок, на котором показан блок данных D, записанный на диск в местоположении A0. Наряду с блоком данных находится инод, который указывает на блок данных D. Обычно блоки данных имеют размер 4 КБ, а размер инодов — около 128 байт.

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

Решение этой проблемы простое — вместо ожидания после каждых двух последовательных записей блока данных мы можем просто сгруппировать некоторые из последовательных записей и временно сохранить их в сегменте, а затем записать их все вместе на диск. Таким образом, вместо того, чтобы ждать, пока диск переместится после каждого блока данных, мы ждем, пока он переместится после каждого x блоков данных, где x — емкость сегмента. Рисунок ниже иллюстрирует эту концепцию.

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

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

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

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

Источник

Использование CD-RW и DVD-RW дисков в Windows 7

Если вставить в привод чистый 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 автоматически выдаст запрос на форматирование этого диска при попытке открыть этот диск:

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

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

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

Даже небольшая сумма может помочь написанию новых статей 🙂

Или поделитесь ссылкой на эту статью со своими друзьями.

Источник

Это первая статья из цикла LFS.

В ней будет затронута начальная подготовка к сборке LFS.

Данная статья подразумевает наличие минимальных познаний в OS Linux.

Для начала немного нудной теории:

На самом деле, Википедии достаточно, чтобы понять что такое Linux – можете почитать в свободное время.

Теперь поговорим о LFS.

Для чего мы собираем LFS? Как минимум – чтобы узнать подробности про каждый пакет в Вашей системе, но самое главное – узнать об их взаимодействии. Так сказать, небольшое изучение Linux изнутри.

CentOS Linux release 7.2.1511 (Core)

В качестве сравнения приведу «железные» параметры своей системы

MemTotal: 7942520 kB

model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz

Чтобы упростить процесс сборки, оставьте неразмеченную область на диске от 20Гб (на всякий случай). Чуть позже мы создадим из этой области необходимый нам раздел и возьмем в пользование.

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

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

Для корректной сборки системы нам необходимы:

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

Хостовая система должна соответствовать следующим требованиям к установленному на машине ПО:

Bash-3.2 (/bin/sh должен быть симлимнком или ссылкой на bash)

Binutils-2.17 (версии новее, чем 2.27 не рекомендованы, т.к. не протестированы)

Bison-2.3 (/usr/bin/yacc должно быть ссылкой на bison или скриптом, который запускает bison)

Gawk-4.0.1 (/usr/bin/awk должен быть ссылкой на gawk)

GCC-4.7 including the C++ compiler, g++ (версии новее 6.2.0 не рекомендованы, т.к. не протестированы)

Glibc-2.11 (версии новее 2.24 не рекомендованы, т.к. не протестированы)

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

• Переход в распакованный каталог

• Выполнение инструкции по сборке – для каждого пакета описаны отдельно

Подготовка к сборке системы:

Для начала задействуем неразмеченное пространство с помощью fdisk:

fdisk [options] change partition table

give partition size(s) in blocks

-b sector size (512, 1024, 2048 or 4096)

-c[= ] compatible mode: ‘dos’ or ‘nondos’ (default)

-h print this help text

-u[= ] display units: ‘cylinders’ or ‘sectors’ (default)

-v print program version

-C specify the number of cylinders

-H specify the number of heads

-S specify the number of sectors per track

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 120.0 GB, 120034123776 bytes, 234441648 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: gpt

Создадим раздел в неразмеченной области с помощью fdisk.

Первой опцией (n) мы говорим, что хотим создать новую партицию,

Далее нажимаем Enter для применения условий по умолчанию – либо вводим необходимые свои. Команда (w) запишет изменения в систему.

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

Command (m for help): m

d delete a partition

g create a new empty GPT partition table

G create an IRIX (SGI) partition table

l list known partition types

n add a new partition

o create a new empty DOS partition table

q quit without saving changes

s create a new empty Sun disklabel

w write table to disk and exit

Command (m for help): n

Partition number (4-128, default 4):

First sector (34-234441614, default 94226432):

Last sector, +sectors or +size (94226432-234441614, default 234441614):

Created partition 4

Command (m for help): p

Disk /dev/sda: 120.0 GB, 120034123776 bytes, 234441648 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: gpt

# Start End Size Type Name

1 2048 2050047 1000M EFI System EFI System Partition

2 2050048 4098047 1000M Microsoft basic

3 4098048 94226431 43G Linux LVM

4 94226432 234441614 66.9G Linux filesyste

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.

The kernel still uses the old table. The new table will be used at

the next reboot or after you run partprobe(8) or kpartx(8)

Ядро не узнает о сделанных вами изменениях, пока вы не перезагрузитесь или не проинформируете его. Сделать это можно, использовав команду partprobe из пакета parted.

Источник

Log-структурированные файловые системы — каждому SSD

Валерия Аврора (Valerie Aurora, formerly Henson)
Перевод Алексея Федорчука, версия 2, причёсанная
Оригинал, 18 октября 2009

От переводчика. Эту статью следует рассматривать как введение в тему файловых систем для твердотельных накопителей любого рода. Она написана ещё до широкого распространения SSD-накопителей, но в преддверии его, и потому сохраняет актуальность.

Введение

Когда речь заходит о log-структурированной файловой системе, большинство разработчиков устройств хранения сразу вспомнит классическую работу Остерхаута (Ousterhout) и Розенблюма (Rosenblum) The Design and Implementation of a Log-structured File System — и почти двух десятилетиях последующих попыток решить неприятную проблему очистки сегмента (см. ниже), за ней последовавших.

Разработчики Linux могли бы подумать о JFFS2, NILFS или LogFS, трёх из нескольких современных log-структурированных файловых систем, специализированных для использования на твердотельных устройствах (SSD). Мало кто, однако, вспомнит о прошивках SSD, хотя flash translation layer (FTL) в современных полнофункциональных SSD в ряде важных аспектов сходен с log-структурированной файловой системой. Экстраполяция исследований log-структурированных файловых систем позволяет нам определить, как получить для SSD максимальную производительность. В частности, полная поддержка команд TRIM, на уровне как SSD, так и файловой системы, будет иметь ключевое значение для поддержания долгосрочной пиковой производительности большинства SSD.

Что такое log-структурированная файловая система?

Log-структурированные файловые системы, как ни странно, произошли от обычных журналируемых файловых систем (logging или journaling file systems). Журналируемая файловая система является нормальной системой write-in-place в стиле ext2 или FFS, отличаясь только наличием журнала записи операций. Далее, в остальной части документа, будет использоваться термин журналируемая файловая система, чтобы избежать путаницы между «логируемыми» и «log-структурированными» файловыми системами).

Журналируемая файловая система хранит на диске состояние файловой системы путём последовательного занесения итога каждой операции записи в журнал (хранящийся в энергонезависимой памяти), прежде чем записать изменения в место их постоянного хранения в файловой системе. Эти или записи журнала содержат достаточно информации, чтобы повторить всю процедуру, если прямая запись в файловую систему прерывается, например, при сбое системы. Эта операция называется восстановлением по журналу. Так что, в общем, все изменения в файловой системе записываются на диск дважды: один раз в журнал, и второй — по месту постоянной дислокации.

Примерно в 1988 году Джон К. Остерхаут (John K. Ousterhout) сотоварищи поняли, что вторую запись можно пропустить полностью, если обращаться ко всей файловой системе как к одному огромному журналу. Вместо того чтобы записывать изменения в журнал, а затем переписывать их по месту постоянного хранения на диске, можно просто один раз дописать данные в конец журнала, где они и останутся. Запись изменений существующих файлов и инодов выполняется copy-on-write — пространство, занятое старой версией, помечается как свободное, а новая версия дописывается в конец занятого пространства. Концептуально, поиск текущего состояния файловой системы — воспроизведение журнала от начала до конца. На практике, log-структурированная файловая система периодически записывает на диске точки проверки (checkpoints): они сохраняют состояние файловой системы на момент их записи, не требуя обращения к журналу. Любые изменения в файловой системе после очередноой точки проверки выделяют путём воспроизведения относительно небольшого количества записей в журнале, следующих за ней.

Одним из интересных преимуществ устройства log-структурированной файловой системы (LFS) является то, что большинство операций записи в файловую систему являются последовательными. Раздел, описывающий мотивацию для Sprite LFS, созданную почти 20 лет назад, показывает, как мало изменилось в мире устройств хранения:

За последнее десятилетие скорость процессоров резко возросла, в то время как время доступа к диску уменьшается медленно. Эта тенденция, вероятно, сохранится и в будущем, и это станет тормозом для всё большего и большего числа приложений.
[…]
Log-структурированные файловые системы основаны на предположении, что файлы кэшируются в оперативной памяти и, что с увеличением объёма памяти кэш будет всё более эффективно удовлетворять запросы на чтение. В результате в дисковом трафике будут преобладать операции записи.

Но подождите, почему мы все ещё говорим о диске? Накопители SSD полностью изменили эксплуатационные характеристики устройств хранения! Диски мертвы! Да здравствует флэшка!

Log-структурированные файловые системы оказываются очень подходящими для флэшек. Одна из особенностей log-структурированного дизайна — то, что в журнал записываются большие непрерывные куски, называемые «сегментами», размером порядка нескольких мегабайт. Чтобы сократить накладные расходы на изменение метаданных и получить лучшую производительность, записи в журнале собираются и записываются последовательно в полностью свободные сегменты. Большинство сегментов в каждый момент времени частично заняты и частично свободны, так что прежде чем записывать в такой сегмент, нужно собрать в нём данные и переместить в другой. Когда файловая система нуждается в свободных сегментах, она сначала очищает существующие частично занятые сегменты, перемещая все находящиеся на нём данные на другой свободный сегмент — в основном это «сборка мусора» (garbage-collects). После этого файловая система может выполнить одну большую потоковую запись в свободный сегмент. Такая система сегментов и их очистки — именно то, что необходимо для эффективной записи на флэш-устройство, с учётом необходимости удаления больших непрерывных блоков с флэшки перед записью на неё.

Совпадение между log-структурированными файловыми системами и флэшками очевидно, когда вы смотрите на файловые системы, написанные для «голых» флэшек — то есть, для устройств без контроллеров выравнивания износа или сбора для записи. Файловые системы, которые должны управлять стиранием блоков и другими деталями «железа» флэшки, почти всегда имеют log-структурированный дизайн. Наиболее используемой из таких файловых систем для Linux является JFFS2, применяемая во многих встроенных устройствах, таких как билетные автоматы и развлекательные системы в самолётах. Не раз я, сев в самолёт, видела сообщения об ошибках флэшки JFFS2 в развлекательных системах на спинках кресел. (К сожалению, для многих тысяч людей логотип Tux теперь будет, вероятно, ассоциироваться с невозможностью смотреть телевизор при дальних на перелётах).

Для SSD, предстающих как блочные устройства дискового стиля — это ныне большинство накопителей потребительского класса — операционки используют обычную файловую систему для обмена с SSD посредством интерфейса блочных устройств (то есть, прочитать блок #37 в этот буфер, записать этот буфер в блок #42, и т.д.). Тем не менее, эта система содержит логический эквивалент log-структурированной файловой системы, которая просто скрыта внутри SSD. Прошивке, которая реализует выравнивание износа, сбор для записи, и любые другие подобные функции, приходится решать те же проблемы, что и log-структурированной файловой системе.

Большинство производителей SSD отказываются раскрывать какие-либо подробности их внутренней прошивки, но мы можем быть уверены, что она имеет много общего с log-структурированной файловой системой. Во-первых, единственный эффективный способ реализации случайной записи в буфер и записи из буфера является их совместная запись в единый блок стирания. Это требует очистки стираемого блока, перемещения всех задействованных блоков в другую область накопителя, и поддержание соответствия между логическим расположением блоков и их физическим расположением — именно того, что делает log-структурированная файловая система. Во-вторых, когда мы действительно из научных публикаций узнаём детали устройства SSD, оно выглядит как log-структурированная файловая система. В-третьих, когда мы смотрим на тестирование долгосрочной производительности SSD, мы видим ту же картину её снижения с течением времени, что и в log-структурированных файловых системах. Подробнее мы поговорим об этом в следующем разделе.

Производительность log-структурированных файловых систем

Log-структурированные файловые системы сегодня являются «родными» для флэш-накопителей, хотя в 1990 году казалось, что они имеют большой потенциал и как дисковые файловые системы. Однако, как всем известно, мы не используем log-структурированные файловые системы на дисках в ноутбуках и серверах. Почему?

Коротко говоря, log-структурированные файловые системы показывают относительно хорошую производительность, пока очистка сегментов — перемещение реальных данных из сегмента для его повторного использования — в основном может выполняться в фоновом режиме, когда файловая система не была занята «реальной» работой. Первая (после основополагающей) большая статья об LFS [PDF] показала, что производительность LFS деградирует до 40% относительно расчётного идеала при реальных значениях занятости диска, соотношении памяти и дискового пространства и трафика файловой системы. Короче говоря, в стационарном состоянии файловая система тратит значительное количество времени обращения к диску на очистку сегментов — перемещение старых данных из сегмента перед его использованием для новых записей. Эта проблема очистки сегментов было предметом активных исследований в течении десяти лет, но ни одно из решений не смогло превзойти файловые системы write-in-place при практическом использовании диска. Это можно сравнить с «уборкой мусора» при управлении памятью; когда память используется мало и с латентностью всё в порядке, удобство garbage collection перевешивает требования к производительности. Но при высокой степени использования диска — уже при 50% — затраты на очистку и периодические простои в ожидании освобождения пространства становятся проблемой.

В первой статье об LFS было показано, что ключ к хорошей производительности log-структурированных файловых систем в том, что пустые сегменты должны создаваться примерно так же быстро, как и использоваться. Скорость записи в файловую систему ограничивается скоростью очистки сегментов. Худший случай наступает тогда, когда файловая система заполнена на X%, и каждый сегмент также заполнен на X%. Производство одной операции очистки сегмента требует сбора данных по формуле:

сегментов и записи старых данных N-1 из этих сегментов. При использовании диска на 80%, получаем:

сегментов для очистки. Если размер сегмента составляет 1 МБ, мы должны были бы прочитать

найденных данных и записать последовательно 4 МБ, прежде чем мы могли бы записать 1 МБ новых данных. (Примечание для педантов: Я использую МБ и КБ в степени 10, а не 2).

Напротив, лучший случай — это файловая система с двумя типами сегментов, полностью заполненными и совершенно пустыми. Лучший шаблон — такой, при котором изменяются все метаданные и данные в одном сегменте, так что когда записаны новые версии, старые версии удаляются, и весь сегмент снова становится пустым. Реальность лежит где-то между этими двумя случаями. Цель log-структурированной файловой системы — в создании бимодального распределения использования сегмента: большинство сегментов должны быть или сильно заполненными, или почти пустыми, при этом заполненные сегменты имеют тенденцию не изменяться. Оказывается, что достичь этого трудно.

К SSD предъявляется дополнительное требование — обеспечить выравнивание износа. Даже в лучшем случае, когда много сегментов заполнено на 100%, и изменения данных в них не записываются, SSD все равно должны иногда перемещать эти сегменты, потому что расширение записи происходит поверх каждого доступного блок флэш-памяти. Это в некоторых случаях добавляет дополнительное перемещение сегмента и делает достижение хорошей производительности даже сложнее, чем в log-структурированных файловых системах на обычных дисках.

Впрок ли урок?

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

В настоящее время, производители следуют стратегии коммерческой тайны для поддержания своего конкурентного преимущества — они подают заявки на патентование отдельных элементов дизайна, но хранят в тайне общую реализацию. Сообщения разработчиков файловых систем типа «Просто нам доверяют» и «Не волнуйтесь, это не ваша головная боль, а наших системных программистов» следуют всякий раз, когда мы запрашиваем дополнительную информацию о реализации SSD. В настоящее время вы не можете особенно спорить с этой стратегией, но, как правило, эта тенденция происходит (и усиливается) не только из нежелания делиться информацией с внешним миром, но и из игнорирования внешней информации, например, ранее опубликованных академических работ.

Одно из самых больших упущений для оптимизации с помощью уроков, полученных от log-структурированных файловых систем, является медленное внедрение поддержки TRIM для SSD. TRIM — это команда для блочного устройства, информирующая его о том, что определенный диапазон блоков больше не используется файловой системой — в основном вызовом free() для блоков. Как уже говорилось ранее, наилучшая производительность достигается, когда пустые сегменты создаются как побочный эффект текущей записи. В качестве простого примера, представьте себе, что сегмент содержит только один индексный дескриптор файла, а всё остальное — данные файла. Если следующая порция для записи в файловую систему перезаписывает все данные файла (и индексный дескриптор в качестве побочного эффекта), этот сегмент становится полностью свободным, и файловая система не должна реально перемещать какие-либо данные перед его повторным использованием. Эквивалентное действие для SSD — это запись в блок, который уже был перезаписан ранее. Внутренне SSD знает, что старая копия этого блока сейчас свободна, и блок может использоваться без копирования его данных в другое место.

Но log-структурированные файловые системы имеют явное преимущество по сравнению с до-TRIM’овыми SSD, а такими были почти все коммерчески доступные SSD на сентябрь 2009 (ныне практически все они TRIM поддерживают — А.Ф.). Log-структурированная файловая система знает, когда область данных на диске стала свободной, даже если она не перезаписывалась. Рассмотрим случай с удалением односегментного файла: весь сегмент освобожден, но никакой перезаписи не было. Log-структурированная файловая система знает, что это произошло, и теперь имеет свободный сегмент для работы. Все же SSD видят несколько маленьких записей для других блоков на диске. Они по прежнему считают, что блоки, использовавшиеся ныне удаленным файлом, всё ещё содержат данные, используемые файловой системой, и нужно продолжать перемещение этих данных. Так как каждый блок устройства был записан по крайней мере один раз, SSD обречены на худший случай в отношении производительности, в котором и запасные блоки, и данные должны быть перемещены каждый раз, когда новый блок вовлекается в использование.

Как мы уже видели, ключ к хорошей производительности log-структурированной файловой системы — наличие свободных или почти свободных сегментов. SSD без поддержки TRIM не знает о многих свободных сегментах, что вызывает огромный недостаток производительности, поэтому то, что SSD поставляются без функции TRIM, просто шокирует. Я думаю, что SSD изначально тестировались на производительность только с файловыми системами write-in-place (кхе, кхе, NTFS) и при низкой степени их использования (скажем, 70% или меньше).

Конечно, всё это умозрительные рассуждения при отсутствии деталей реализации от производителей SSD. Возможно, некоторые программисты прошивок SSD придумали совершенно новые алгоритмы для ремаппинга и сбора для записи, которые не похожи на все log-структурированные файловые системы, и характеристики производительности и оптимизации, которые мы видели до сих, просто кажутся совпадающими с log-структурированными файловыми системами. Тем не менее, до сих пор кажется, что исправление SSD по способу, поддерживаемому log-структурированной файловой системой, способствовало бы получению высокой производительности. Полная поддержка TRIM как SSD, так и файловыми системами будет иметь ключевое значение для высокой производительности в долговременной перспективе.

Источник