btrfs vs ext4

Ты из верующих, что дефрагментация убивает ресурс ssd?

Я из верующих, что контроллер сам постоянно миксует ячейки, и дефрагментация не спасет

Не так давно удалось протянуть несколько месяцев на сыплющемся диске вместе с btrfs и data=DUP. Это как metadata=DUP, только data, а не metadata. Свободного места вдвое меньше объёма диска, зато надёжно! К тому же профиль DUP ещё и был применён к данным не с самого начала, а чуть позже, уже на живой системе. Применился не с первого раза, кстати, несколько раз выдавал ошибку чтения. Причём пока он не был применён окончательно, btrfs не высказывала абсолютно никакого недоумения по поводу частичной дублированности своих блоков.

И потом при каждом обращении к сбойному сектору был сначала фриз всей системы, а потом серия записей в логе: read error corrected. В итоге так ничего и не потерялось! Вроде бы

Стоп! Какое отношение контроллер ssd имеет к фрагментации? Это разные уровни организации хранения информации.

Это как? И, главное, зачем?

Люди, научитесь выражатся по-человечески. Что такое миксинг ячеек? Что «как»? Что «зачем»?

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

какие ещё отношения, если в реальной работе все эти твои уровни проходятся до самого нижнего?

Ладушки, всем спасибо, пацаны и пацанессы!

Я выбираю здоровый консерватизм! Я выбираю ext4!

серьёзные дяди доверяют только jfs

Ставлю арчик на ноут с ssd. Задался вопросом выбора ФС.

f2fs

Для SSD есть специально созданная F2FS. Ставить другую надо только в том случае, если можешь четко объяснить зачем тебе это нужно.

F2FS-Zstd-Linux-5.7-Pull

Ну как появится 6.3 LTS (если сразу в 10.3 не переименуют), то можно будет начать пользоваться.

А ты думаешь, что ssd может выполнять бесконечное количество операций I/O в секунду? Фрагментация на ssd точно так же бъет по производительности. И дефрагментация не сильно бъет по ресурсу перезаписи, поскольку делается не постоянно, а только в случае наличия фрагментированных файлов.

Например, если я не доверяю f2fs хранение своих данных и согласен использовать ее только как корень?

работает быстрее ext4

Это с чего бы? Фич больше гораздо и работает быстрее? Хорошо бы, чтоб не медленнее.

Фрагментация на ssd точно так же бъет по производительности.

По производительности бьёт «винегрет» в файлово-инодной таблице (все файловые операции просаживает), а про фраги, тем более на ssd забудь. Их надо ликвидировать только если это отражается на той самой файлово-инодной таблице.

btrfs тормоз, нужно «модно и молодежно» для опытов - F2FS или XFS, нужно для «поставил и забыл» на ноут - ext4.

Стоп! Какое отношение контроллер ssd имеет к фрагментации? Это разные уровни организации хранения информации.

Ты правда не знаешь, зачем нужна дефрагментация на hdd, и почему это бессмысленное занятие на носителях без движущихся частей, а на ssd в особенности? :-)

Так, давай условимся: что такое «винигрет в файлово-инодной таблице»? Фрагментация — это когда один файл (или структура фс) записан не непрерывной последовательностью, а кусками. Которые еще могут быть разбросаны по всему диску. Фрагментация — это термин, а «винигрет в файлово-инодной» — какой-то эвфемизм. Ты под винигретом подразумеваешь фрагментацию? Или что это такое?

Расскажи, почему.

для опытов - F2FS или XFS

Каких к чорту опытов? XFS - идеальная торрент-помойка.

Ты под винигретом подразумеваешь фрагментацию?

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

Расскажи, почему.

Вообще-то уже рассказал: «на носителях без движущихся частей». Это основное. А про SSD тебе уже чуть раньше написали дополнительно, про то, что контроллер пишет не последовательно ни разу, а выравнивая процент износа ячеек.

Да, у ssd лучше с рандомным чтением/записью, чем у винтов. Но все равно, производительность будет ниже.

Но все равно, производительность будет ниже.

Да правда что ли? А увидеть можно? :-)

Вот. Написано то, что я и сказал. Бьет по I/O performance.

Но следует признать, что такого вреда, как на hdd не будет.

Здесь тоже есть, хотя тут больше про пользу trim.

Написано то, что я и сказал. Бьет по I/O performance.

Windows OS. Что-то дальше читать не хочется. У этого говна без ssd что хочешь вылезет.

В линуксе физика работы ssd другая? Опять же, я признаю, что такого ахтунга, как на винте не будет. Но по I/O оверхед все равно есть.

использую XFS везде. она таки поустойчивей будет к отрубанию электричества.

В линуксе физика работы ssd другая?

В Линуксе несвязанных с ssd проблем меньше.

Но по I/O оверхед все равно есть.

Объяснить методику возникновения можешь?

по I/O оверхед все равно есть

Из пушки по воробьям! См. btrfs vs ext4 (комментарий)

Здесь тоже есть

https://superuser.com/questions/97071/do-ssds-get-fragmented-and-if-they-do-is-that-an-issue

А что именно там есть про необходимость дефрагментации SSD? На первый взгляд — ничего.

Yes, SSDs do get fragmented. Does it impact performance as much as regular hard drives? No.

Solid-state drives DO NOT require defragmentation.

This is yet another benefit of SSDs over spinning HDs: fragmentation is no longer an issue.

Вот. Написано то, что я и сказал. Бьет по I/O performance.

Рассуждения. Тесты бы посмотреть. Для hdd такие есть

1 2

. . . . . .

Хотя да, здесь https://www.hanselman.com/blog/TheRealAndCompleteStoryDoesWindowsDefragmentYourSSD.aspx

пишут, что дефрагментация нужна. Для метаданных.

дефрагментация нужна. Для метаданных.

О чём, собсна, речь и была. См. btrfs vs ext4 (комментарий)

бессмысленное занятие

Побенчмаркай (random read с разным размером блока от 4k до 1M) и удивись.

Как уже написали, IOPSы в SSD не бесконечные. Если ФС сильно фрагментирована (как обычно бывает с btrfs), то дефрагментация с целевым размером блока хотя бы 256k очень даже положительно влияет на производительность.

Объяснить методику возникновения можешь?

Объясняю: константный per-IO оверхед в SSD маленький, но ненулевой.

положительно влияет на производительность

Больше, чем btrfs vs ext4 (комментарий) ?

Как уже написали, IOPSы в SSD не бесконечные. Если ФС сильно фрагментирована (как обычно бывает с btrfs), то дефрагментация с целевым размером блока хотя бы 256k очень даже положительно влияет на производительность.

Я готов поверить в метаданные, когда они вместо, например, 8-и разных ячеек (ага, по 512К) собираются в одну. А если у тебя блок данных весь 4К и следующий 4К, то кто тебе гарантирует, что они последовательно лежат? Да они вообще на разных микросхемах могут быть физически.

то кто тебе гарантирует, что они последовательно лежат? Да они вообще на разных микросхемах могут быть физически.

Гарантирует жизненный опыт. Размер erase block на современных SSD больше 4K.

Размер erase block на современных SSD больше 4K.

Ну ладно, посчитаем, что уговорил.

Имею в пользовании evo850 с debian на ext4, и для тестов evo860 c manjaro на btrfs. Разницы в скорости особой нет. По износу оба диска живут уже почти 3 года, проблем нет. В бтрфс только удобно таймшифтом делать снимки в случае чего. Если нужно куда-то в стабильную машину пихать, думаю лучше ext4, а поиграться btrfs. Хотя если подумать, с ней у меня проблем не было, но часто слышу много криков какая она не стабильная.

1. В идеале не доверять хранение своих данных нужно ЛЮБОЙ файловой системе и делать пару-тройку бэкапов.
2. По своему опыту скажу, что чаще терял данные на ext4 (3 раза), чем на f2fs (0 раз).

В идеале не доверять хранение своих данных нужно ЛЮБОЙ файловой системе и делать пару-тройку бэкапов

Это да.

лорчую по опыту на локалхосте

Бери ext4 и не делай мозги. Мне на ноуте btrfs ничего кроме головняка не дала.

Нет ФС, кроме ext4, и Эндрю Мортон — автор её.

Эндрю Мортон — автор её

28 June 2006, Theodore Ts’o, the ext3 maintainer, announced the new plan of development for ext4.[6]

ext4 Developer(s) Mingming Cao, Andreas Dilger, Alex Zhuravlev (Tomas), Dave Kleikamp, Theodore Ts’o, Eric Sandeen, Sam Naghshineh, others