Дефрагментация на SSD надо ли ?

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

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

Конечно надо, делай.

скорость рандомного чтения не сильно отличается от скорости линейное чтения. разницу не почувствуешь.

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

Я замерял ранодмную, она многократно меньше последовательной

Что касается ресурса, дефрагментация никак на него не повлияет, даже теоретически увеличит, в статье указывается, что при перезаписи 4 кб может перезаписываться 64 кб блок

Не огромный? Да ладно? Что ж такого нужно делать, чтоб он сдох раньше, чем устарел (само собой я говорю только о современных)?

В линуксовых файловых системах дефрагментация нужна только если была запись на ФС при свободном месте меньше ~5%. Если таких случаев не было, то думать о дефрагментации бессмысленно.

Впрочем, гипотетически кривой софт может сфрагментировать свои файлы. Я подозреваю, что установщик worldoftanks в вайне так делает (он ведь под капотом является торрент-клиентом, но делает ли он fallocate?).

В линуксовых файловых системах дефрагментация нужна только если была запись на ФС при свободном месте меньше ~5%. Если таких случаев не было, то думать о дефрагментации бессмысленно.

Я давно прикидываю нужно или нет, склоняюсь к тому, что хуже точно не будет, у ssd есть преимущество, дефрагментация не занимает много времени и не должна мешать другим программам, чего не скажешь про hdd, где все становится колом

Больше быдлоблогов быдлофирм на Швабре читай.

В линуксовых файловых системах дефрагментация нужна только если была запись на ФС при свободном месте меньше ~5%.

А что если на ext4 создан qcow2 образ для Win. Нужна в таком случае дефрагметация?

А что если на ext4 создан qcow2 образ для Win. Нужна в таком случае дефрагметация?

Тут тогда нужен дефраг и внутри виртуалки и в винде, иначе это не имеет смысла

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

Кейс, в котором точно нужна: уменьшить NTFS раздел с виндой.

Да, особенно на ФС с CoW. За фрагментацию ты платишь процессорным временем.

Вообще в идеале

Улучшить файловую таблицу?

Савсеем там упоролись?

А для линуксовых ФС уже сделали нормальные дефрагментаторы, или это вопрос «как бы нам поделить шкуру неубитого медведя»?

Вот ты и сделаешь)

Во всех нормальных есть.

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

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

Размер erase-блока зачастую составляет 128 КиБ. Если у файлов фрагменты уже больше 128 КиБ, дефрагментация вряд ли принесёт пользу.

нет целевой функции дефрагментации

Есть: уменьшить write amplification.

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

Есть одна тонкость, если дефрагментировать и выполнить fstrim то накопитель точно будет знать где свободно и сумеет все оптимизировать если надо.

Кстати получается что при дефраге SSD нужно выполнять fstrim, чтоб получить лучший результат

но нет дефрагментации метаданных, которая бы не помешала.

Это что? e2fsck -D? или иноды перетасовать хочется?

А чем просто fstrim не устраивает?

Это что?

Директории, где имена файлов перечислены. Их как ext4 создаёт, так и расположение не меняет. Иногда директория разрастается до нескольких мегабайт, и тогда открываешь её, и ядро собирает все эти мегабайты по мелким кусочкам. Сделать ничего нельзя. Ну или я что-то пропустил.

e2fsck -D

Я не заметил, что эта функция что-то даёт. Её же вообще добавили, чтобы в старые директории из ext2 добавить индексы htree. У меня все ext4 были созданы сразу как ext4, поэтому там уже есть htree.

иноды перетасовать

Иноды же уже в отведённых местах лежат. Их нет смысла двигать.

Я не заметил, что эта функция что-то даёт

Она перестраивает индекс директории, если в нём много дыр. Например, после touch {1..1000000}; rm {1..500000}. Первый случай тоже иногда лечит.

Хм. Это не проверял. Мне было интересно собрать все фрагменты куда-нибудь рядом.

Их как ext4 создаёт, так и расположение не меняет. Иногда директория разрастается до нескольких мегабайт

А в ряду первых говорил, что это всё ненужно: Дефрагментация на SSD надо ли ? (комментарий)

На смонтированной ФС ?

На смонтированной ФС ?

fsck на смонтировной фс? Флаг в руки, транспарант на шею,…

Твоя ссылка указывает не на моё сообщение, а на сообщение какого-то анонима.

не на моё сообщение

Мож и по другому: Улучшить файловую таблицу? . Найдёшь свои сообщения, али помощь нужна?

скорость рандомного чтения не сильно отличается от скорости линейное чтения. разницу не почувствуешь.

Скорость сильно отличается, но разница между ней гораздо меньше, чем у HDD, поэтому проблема не так заметна.

https://hsto.org/getpro/habr/comment_images/7ac/958/cb0/7ac958cb053b389cd73ef4dadfb60526.png

Замерял при каком размере блока? Попробуй 128 МБ. Разницы по идее не будет. Ext4 по дефолту такой размер использует.

128 мегабайт размер блока ? То есть под один 4 кб файл выделяется 128 мегабайт ?

Нет, файловая система старается держать файл в этом логическом блоке. Минимальный блок 4 КБ.

Единственное что могу придумать в этом смысле это дефрагментировать по сути надо не Файлы, а свободное место, а потом его потримать. Для каких-то более частных случаев и паттернов применения наверное что-то и получше можно придумать

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

128 MiB это размер block group. В старых extN весь диск делился на группы блоков, в начале каждой была таблица инодов. Соответственно, нигде в extN не было более 128 мегабайт сплошного свободного места.

быдлоблогов быдлофирм на Швабре

Доо, то ли дело лороиксперды, лезущие со своим ценным мнением, даже не осилив понять вопрос.