После дефрагментации увеличилось занятое место на Btrfs

как их удалить хз

Наверное, никак. Дефрагментировать ФС, которая работает по принципу CoW - так себе затея))

Скажи ещё, что на SSD, и ты сделаешь мой день!

Случайный доступ на SSD к небольшим фрагментам может быть раз в 10 медленнее, чем линейный.

Для ssd важна дефрагментация в пределах erase block. «Сквозная» дефрагментация смысла не имеет, разве не так?

«Сквозная» дефрагментация смысла не имеет, разве не так?

Кому как. Какой-нибудь SSD может выдавать 400-500 МБ/с на линейном чтении, но при случайном доступе там легко может оказаться порядка 20 МБ/с. В бенчмарках показывают потрясающие скорости и на случайном чтении, но только при очень большом числе одновременных запросов. Такое в обычных применениях бывает редко, зато отлично выглядит в маркетинговых материалах.

Даже с падением скорости, это всё ещё на порядок быстрее HDD, так что не особо заметно.

Но контроллер же постоянно тасует сектора для выравнивания износа?

И вообще, как дефрагментатор может добиться глобальной линейности для файла на ssd?

Это всё равно не стоит кхм-кхм, растраты ресурса записи.

Но контроллер же постоянно тасует сектора для выравнивания износа?

У меня нет фактов на руках, но раз линейная скорость чтения сохраняется высокой, контроллер скорее всего читает данные заранее.

И вообще, как дефрагментатор может добиться глобальной линейности для файла на ssd?

А этот вопрос меня начал беспокоить сразу же, как я задумал сделать свой дефрагментатор. Как-то все привыкли, что если делать дефрагментацию, то все файлы должны стать линейными. Но зачем? Даже на HDD всё равно будут прыжки к метаданным. Смысла в абсолютной линейности нет. Достаточно, чтобы куски были достаточно большими, чтобы задержки переключения не снижали скорость больше, чем на 20%, например.

Для SSD достаточно, чтобы минимальные куски файлов не были меньше одного или нескольких erase block, и были выровнены на границу этих erase block.

Вот уж о чём точно не стоит беспокоиться, так это о ресурсе записи.

Что такое erase block?

NAND память стирается блоками. Часто такой блок имеет размер 128 киБ. Поэтому если ты хочешь перезаписать 4096 байт где-то посередине, нужно сначала прочитать все эти 128 киБ, потом стереть разом, потом записать заново старые данные, заменив те 4096 байт на нужные. Такие блоки и называют erase block.

А эффект записи 128 киБ вместо 4 киБ — write amplification.

Спасибо.

Точно так? Стирается только весь блок разом. А записывается тоже только целиком? Если есть «недавно» стёртый блок, его нельзя записывать посекторно?

Если есть «недавно» стёртый блок, его нельзя записывать посекторно?

Конечно, ты прав, стёртые можно записывать постранично.

Я имел в виду ситуацию, когда в erase block уже есть нужные данные, и нужно только заменить часть. Тогда если без трюков с переназначениями, придётся использовать цикл чтения-модификации-записи.

Если файловая система не делает различий между типами носителей и деградирует свои скоростные характеристики доступа к данным независимо от типа носителя, то у неё ОЧЕНЬ большая проблема с организацией метаданных.

Если после процедур оптимизаций у файловой системы уменьшается ещё и полезный объём свободного пространства, то это проблема В КВАДРАТЕ, так как по-видимому, объём метаданных вырос, а толку от этого не прибавилось.

Копия при изменении файла (например дефрагментацией) создается только при созданных ранее снапшотах файловой системы. есть ли они можно проверить так (указываем путь, куда смонтирована файловая система. например / , если смонтировано в корень)

sudo btrfs subvolume show /

И чо?

Объем всего занимаемого пространства увеличился на 30 гб, на диске, кроме мелких кешей, логов и прочего мелкого мусора, ничего не могло увеличить размер. Вряд ли это будут аж 30гб

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

Очень большом - это сколько? В одном журнале используют iometer с 32 I/Os (да и глубина SATA NCQ как раз 32). Для одного популярного SSD получили следующие числа. При «последовательном» (блок 128 КБ) чтении - 520 МБ/с, записи - 480 МБ/с. При «случайном» (блок 4 КБ): чтение где-то 83000 (т.е. 324 МБ/с), запись 61000 (т.е. 238 МБ/с). Как и ожидалось, медленнее, но незначительно.

Очень большом - это сколько?

32.

Такое кроме как в бенчмарках бывает вообще? IMHO, программы грузят файлы последовательно.

чтение где-то 83000 (т.е. 324 МБ/с), запись 61000 (т.е. 238 МБ/с).

Какие-то подозрительные числа, запись медленнее чтения.

Чтение это честный доступ к данным, не смухлюешь. Запись же делают куда-нибудь в быструю область, а потом потихоньку раскладывают по основному хранилищу. Не помню, чтобы в бенчмарках, которые я видел, запись была медленнее. Это как в Linux: read() всегда тормозит, write() почти всегда дешёвый, так как данные уходят в writeback кеш.

И все же - каким образом было выявлено, что место скушано? Если есть подозрение, что место все же куда-то ушло, то есть замечательная программка для анализа использованного пространства. баобаб. запускать от рута

sudo baobab /

sudo apt install baobab

sudo btrfs subvolume show /

кроме мелких кешей, логов и прочего мелкого мусора, ничего не могло увеличить размер. Вряд ли это будут аж 30гб

вообще-то запросто

ТС, вы ведь смотрите занятое место через btrfs filesystem df?