В XFS завезут CoW

Я лучше у тебя спрошу, что ты понимаешь под незанятым местом.

Я первый спросил :-P

Что из этого приводит к потере данных?

Вот, например: https://bugzilla.kernel.org/show_bug.cgi?id=64191

Наверное, есть и ещё, я внимательно не искал.

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

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

Понял. Давай уберем из уравнения SSD. Как обычный HDD отличает?

Понял. Давай уберем из уравнения SSD. Как обычный HDD отличает?

Никак. Это ему не нужно.

Никак. Это ему не нужно.

Правильно. Потому что это блочное хранилище. А теперь вернем в уравнение SSD. Что изменилось-то?

Правильно. Потому что это блочное хранилище. А теперь вернем в уравнение SSD. Что изменилось-то?

Изменилось то, что SSD для ускорения операций записи может стирать незанятые блоки. Для этого SSD должен знать, какие блоки не заняты. Если этого не делать, производительность SSD со временем деградирует.

I tried to make XFS Filesystem with -d agcount=1 option. This setting is not recommended

Хорошая попытка, продолжай еще.

А теперь вернем в уравнение SSD. Что изменилось-то?

Wear.

Рекомендована опция, или нет - дело десятое. И ты мнея не понял, я не пытаюсь здесь кому-то что-то доказывать, и спорить. Ты просил баги, я их привёл. Я даже уверен, что в ext4 тоже есть незакрытые баги с потерей данных.

Вот, кстати, для btrfs: https://bugzilla.kernel.org/show_bug.cgi?id=60544

Рекомендована опция, или нет - дело десятое.

Нет, это очень важно. Я аналогично могу включить barrier=0 на ext4, рубануть питание, а после порчи за-sync'анных файлов орать, что ext4 - говно.

Нет, это очень важно. Я аналогично могу включить barrier=0 на ext4, рубануть питание, а после порчи за-sync'анных файлов орать, что ext4 - говно.

Это будет штатным поведением файловой системы. По ссылке - баг. Но, ещё раз, это не важно. Я ни где не утверждал, что ext4 надёжнее btrfs или xfs.

Изменилось то, что SSD для ускорения операций записи может стирать незанятые блоки. Для этого SSD должен знать, какие блоки не заняты. Если этого не делать, производительность SSD со временем деградирует.

Сейчас OP-зона в некоторых случаях достигает 150% от емкости носителя, презентуемой пользователю. И есть мнение, что в этом случае TRIM уже слегка лишняя сущность. Но мы можем провести тест, у меня как раз на руках появилась свободная партия enterprise-grade NVME дисков.

Сейчас OP-зона в некоторых случаях достигает 150% от емкости носителя, презентуемой пользователю. И есть мнение, что в этом случае TRIM уже слегка лишняя сущность. Но мы можем провести тест, у меня как раз на руках появилась свободная партия enterprise-grade NVME дисков.

Всего-то надо пару раз под завязку забить винт, и всё.

Они не вдавались в детали, ссылаясь на NDA. Но я не очень представляю, зачем им было мне врать.

А я не представляю, чем он мог им помешать. И если таки мешал, то могли бы просто не обрабатывать.
По поводу необходимости стирать блоки перед записью уже упомянули

Ну вот интел сами все делают, микрон сами делают память и пишут прошивки для контроллеров, самсунг тоже память делает, про контроллеры не знаю.

Всего-то надо пару раз под завязку забить винт, и всё.

Все интереснее. Характеристики диска, которые публикуют вендоры — это характеристики как раз после двойной забивки винта.

Какие конкретно характеристики?

IOPS и задержки.

1. Они специально отключают trim в ОС перед тестированием?
2. Какое это имеет отношение к делу?

Они проводят блочные тесты. Без TRIM.

Но какое это имеет отношение к делу?

Ну вот интел сами все делают

Делали раньше. Теперь не делают.

самсунг тоже память делает, про контроллеры не знаю.

Контроллеры тоже делает.