LINUX.ORG.RU

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

 , ,


1

5

Прочитал статью https://habr.com/ru/company/ruvds/blog/478748/

Там сказано

... то в реальной жизни диск сильно фрагментируется. В этом случае даже последовательная запись превращается по скорости практически в случайную.

Учитывая что рандомная запись чтение это тормоза получается, что дефрагментация таки желательна, особенно зная что на SSD она не занимает много времени ?

★★★

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

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

pfg ★★★★★ ()
Ответ на: комментарий от pfg

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

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

Lordwind ★★★★★ ()
Ответ на: комментарий от pfg

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

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

ism ★★★ ()
Последнее исправление: ism (всего исправлений: 1)
Ответ на: комментарий от pfg

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

kardapoltsev ★★★ ()

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

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

legolegs ★★★★★ ()
Последнее исправление: legolegs (всего исправлений: 1)
Ответ на: комментарий от legolegs

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

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

ism ★★★ ()
Ответ на: комментарий от legolegs

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

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

NightCat ()
Ответ на: комментарий от NightCat

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

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

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

ism ★★★ ()

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

Dispetcher14 ★★★★ ()

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

anonymous ()

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

anonymous ()

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

hobbit ★★★★★ ()

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

cobold ★★★★ ()

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от cobold

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от cobold

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

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

ism ★★★ ()
Последнее исправление: ism (всего исправлений: 2)
Ответ на: комментарий от i-rinat

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от legolegs

Это что?

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

e2fsck -D

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от legolegs

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

i-rinat ★★★★★ ()
Ответ на: комментарий от ism

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

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

anonymous ()
Ответ на: комментарий от pfg

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

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

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

ValdikSS ★★★★★ ()
Ответ на: комментарий от ism

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

Legioner ★★★★★ ()
Ответ на: комментарий от ism

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

Legioner ★★★★★ ()
Ответ на: комментарий от i-rinat

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

cobold ★★★★ ()
Ответ на: комментарий от cobold

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

i-rinat ★★★★★ ()
Ответ на: комментарий от ism

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

i-rinat ★★★★★ ()
Ответ на: комментарий от LongLiveUbuntu

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.