https://man7.org/linux/man-pages/man8/e4defrag.8.html

Так даже в XFS и даже в СУБД причем онлайн. Что-то они слишком уж самонадеянно разработчики заявляют, что дефрагментация для ZFS ненужна, ленятся просто.

она там архитектурно бессмысленна

Ssd 100% подвержены фрагментации и после security erase даже intel s3700, например, работают заметно шустрее. Причем это внутрення фрагментация, не связанная с ырагментацией файлов в ФС.

там чуть из-за другого работает быстрее. там есть такое понятие - сборщик мусора. если диск аллоцирован полностью (или если это консюмерский) - перезапись ячейки всегда очень длительный процесс (ячейки там чуть ли не по 32 мегабита чтоль в некоторых из) посему он там использует аналог cow на полную - пишет в новое место, а старое затирает. если диск саллоцирован полностью и без трима или резервного пространства - свободное место быстро не найти, и оно начинает тормозить. а сборзик мусора как раз берёт оттриммированные куски и освобождает их.

В моем случае тормозило при чтении (send).

Я же не спорю, что если в старые дефрагментированные данные что-то снова писать новое, то они опять станут фрагментированы из-за COW. Речь о том, что бывают пулы в которые пишутся восновном новые данные, а старые изменяются редко. Например, документно-учетные базы данных архивного характера либо базы с топологиями для развертывания IaC имеют именно такой характер, не говоря уж о пулах с рабочими файлами, где меняется очень мало чего только в новых проектах. Лично у меня почти все ZFS нагрузки именно такого характера и мне важен мой use case, а не абстрактное поведение COW ZFS на базе данных какого-нибудь Zabbix/Prometheus или ZoneMinder.

значит выбор - либо сервисы со стороны зфс, либо отсутствие фрагментации и линейная фс

Мне помогает send | receive, но лучше бы это автоматически. Были б деньги, написал бы сам автоматику.

Это костыли

Если тебе критична фрагментация - зфс тебе не подходит

Лвм

У тебя не те нагрузки чтобы это влияло как-то

Тогда виртуалки снеси в лвм

Там и снапшоты и все есть

Только ZFS и репликация и спасли мои данные, если бы не ZFS, то все, полный каюк.

^

Это всегда и везде так

Той же ехт4 или хфс

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

Значит мирись :)

ZFS все решает, как можно мириться с фашисткими ублюдками, нападающими на мое благополучие.

Тебе нужно мириться с архитектурой и производительностью

там чуть из-за другого работает быстрее. там есть такое понятие - сборщик мусора. если диск аллоцирован полностью (или если это консюмерский) - перезапись ячейки всегда очень длительный процесс (ячейки там чуть ли не по 32 мегабита чтоль в некоторых из) посему он там использует аналог cow на полную - пишет в новое место, а старое затирает. если диск саллоцирован полностью и без трима или резервного пространства - свободное место быстро не найти, и оно начинает тормозить. а сборзик мусора как раз берёт оттриммированные куски и освобождает их.

был бы дб2 мультиверсионным, ты бы меня понял на все сто процентов)

Я уже разрабатывал bash скрипт для автоматической репликации на бэкапы.

Ты сравнил смазать цепь велосипеда с разработать чуть ли не новый аатопилот для боинга

А что же подходит, если мне нужен почти весь функционал ZFS + еще дефрагментация?

Так я предлагаю всего лишь автоматизировать send | receive для кейса дефрагментации, только и всего.

Тебя спасёт жирная хранилка с батарейкой и на много памяти)

Я не доверяю хранилкам, тем более жирным, тем более с батарейкой. Доверяю только ZFS без батарейки на максимально простом железе типа Core2. По крайне мере для критически важных проектных пулов для сорцов, где ненужна высокая производительность как в проде.

Я не доверяю хранилкам, тем более жирным, тем более с батарейкой. Доверяю только ZFS без батарейки на максимально простом железе типа Core2. По крайне мере для критически важных проектных пулов для сорцов, где ненужна высокая производительность как в проде.

2 посиавь цеф

Еще не хватало, мне важен не SLA, а сохранность данных, а это ZFS (а не CEPH).

2 и как твои реплики спасут если очередная альфаверсия зфс пошлёт везде кривой сенд?

Сохранность это бекап, а репликация это как раз сла

Держать два пула для дефрага? Ты серьёзно?

У меня на источнике только недавно случился переход с 0.7.12 на 0.8.6, и старые то снэпшоты по крайне мере никуда не денутся на репликах.

Why not, тормоза лучше?

А это ещё надо разобраться как там сенд работает, может ли от фонаря сектор писать или нет

Снэпшоты же консистентны? Как последующие могут повлиять на предыдущие?

Купи ленту)

Озфс уже не бэта?

А разве есть в природе что-то надежнее ZOL 0.8.6 кроме проприетарного ZFS ? Btrfs ? :) ext4 ога щаз ...

в природе есть очень навороченные хранилки..

Свежо придание. Классический вопрос, что с ними произойдет после РЭБ атаки по питанию.

кста, у тебя память с четностью везде?)

Нет конечно, уже 10 лет как, причем. Ессно я ее много раз гонял в memtest по нескольку дней на каждом хосте. Смешно слушать, что для ZFS необходим ECC, а для например XFS необязательно. Может еще проц с ECC поискать?

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

На прод серверах в ПФР конечно была ECC память. А дома какая ECC, тем более на Core2. На AM3 еще можно сделать not registered desktop ECC DDR3. Ну или настоящие серваки брать.

у меня г8 дома. шумит зараза. почти всегда выключен