Может всё же речь про то, что мета по умолчанию на 1 девайс пишется 2 копиями?

Я не находил каких-то пруфов, что ZFS умирает от гавно ССД

Я думаю, что в btrfs данные тоже должны выживать, т.к. она cow. Но с её логикой работы я слабо знаком

Я думаю, что в btrfs данные тоже должны выживать, т.к. она cow. Но с её логикой работы я слабо знаком

В SDS можно спросить у него, что бывает с BTRFS если SSD игнорит fsync

Видимо нет

Я думаю, что в btrfs данные тоже должны выживать, т.к. она cow. Но с её логикой работы я слабо знаком

А на практике. Чуть-чуть пяка в данных и вся фс в труху

Восстановить чем-то можно?

Восстановить чем-то можно?

Кирпич

Спасибо за инфу, не даром я её не люблю

Поэтому да, диск для любой ФС не должен быть гавно

В принципе 840,850,860 evo и pro не подводили ни разу меня, но без PLP всё равно гарантий нет

Они fsync не игнорят насколько я помню

Ну вот приедут все заказанные диски - попробую сливать. А пока развивается следующим образом: Попробовал, выключив север, убрать возможную проблему контактов: переприсоединил SATA Data к тому диску, который помечен SLOW. После перезагрузки сервера (опять только со второй попытки - первая висела более получаса 😞 ) состояние zpool status изменилось: https://pastebin.com/9UjVABw3 То есть тот диск, который был SLOW, перестал (?) быть медленным. Более того, ресилверинг на нем прекратился (на двух других дисках ресиверинг как будто продолжается)! Зато статус SLOW получил совсем другой диск. Оставил пул вчера в этом состоянии. Сегодня, спустя более 30 часов, процент ресилвенга не изменился, прогноза времени его завершения нет. То есть как будто все зависло. Файловая система не совсем мертва: некоторые команды ls показали содержимое некоторых папок, но довольно быстро дошел до папки, на которой ls опять подвесил терминал (который был отрыт через ssh). Так что спасти данные копированием пофайловым точно не получится, и что-то мне кажется, что и send/receive не получится. Но завтра, не дожидаясь получения дисков для всего пула, попробую send/receive какого-нибудь одного датасета.

Приступил к спасению данных. Начал с одного датасета размером 3.61T: root@docker09:~# zfs list -o space my/93 NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD my/93 3.13T 3.61T 0B 3.61T 0B 0B Почему-то send собирается передавать в снапшоте аж 11.3T 😳 root@docker09:~# date; zfs send -v my/93@send93 | zfs receive s11/93; date Mon Dec 4 03:22:54 PM UTC 2023 full send of my/93@send93 estimated size is 11.3T total estimated size is 11.3T Это я что-то сделал не так, или это признак какого-то повреждения пула 🤔? UPD Нагуглил, что это обычное дело - превышение оценки по сравнению с реальным объемом данных Правда, объясняют это дедупликацией, которой у меня совсем нет ...

Приступил к спасению данных. Начал с одного датасета размером 3.61T: root@docker09:~# zfs list -o space my/93 NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD my/93 3.13T 3.61T 0B 3.61T 0B 0B Почему-то send собирается передавать в снапшоте аж 11.3T 😳 root@docker09:~# date; zfs send -v my/93@send93 | zfs receive s11/93; date Mon Dec 4 03:22:54 PM UTC 2023 full send of my/93@send93 estimated size is 11.3T total estimated size is 11.3T Это я что-то сделал не так, или это признак какого-то повреждения пула 🤔? UPD Нагуглил, что это обычное дело - превышение оценки по сравнению с реальным объемом данных Правда, объясняют это дедупликацией, которой у меня совсем нет ...

Сжатие включено?

попробуйте send с опцией -c, он не будет разжимать данные при пересылке. объём должен уменьшиться

А, значит, разжимает?

разжимает. с опцией -c не будет разжимать

Странно: вот сейчас передал 777ГБ, и в новом датасете ровно столько же появилось. То есть как будто не разжимает...

Но ведь он же повторяет на новом полностью датасет исходный. То есть и размер блока со старого переносит, и компрессию оставляет ту же, что была в исходном. Тогда зачем ему разжимать и на другой стороне сжимать?

Странно: вот сейчас передал 777ГБ, и в новом датасете ровно столько же появилось. То есть как будто не разжимает...

скорее всего разжимает, а на приёмнике снова сжимает. Двойная работа. но -с точно уменьшает объём передачи, уже так делал, намного быстрее всё получается

Но ведь он же повторяет на новом полностью датасет исходный. То есть и размер блока со старого переносит, и компрессию оставляет ту же, что была в исходном. Тогда зачем ему разжимать и на другой стороне сжимать?

1) the UNIX philosophy is in play here :-) Sending the data uncompressed to stdout allows you to pipe it into various transport or transform programs. 2) compatibility, including future-proof somewhat (the zfs-send format explicitly does not guarantee that it won't change incompatibly). I mean stransfer of data between systems that do not implement the same set of compression algoritms in ZFS.

Но ведь он же повторяет на новом полностью датасет исходный. То есть и размер блока со старого переносит, и компрессию оставляет ту же, что была в исходном. Тогда зачем ему разжимать и на другой стороне сжимать?

Ну и попроще если

а еще можно пропускать разжатый стрим через zstd -zc ... zstd -dc тогда может и лучше понасжимать (сэкономить трафик)

Или если исходный без компрессии

кх нет смысла тестить на бтрфс и зфс.

очевидно что компрессия поблочно хуже компресси всего несжатого стрима

Весь несжатый стрим вряд ли влезет, это обычно терабайты. А если блоки стандартные 128к или больше, думаю ощутимой разницы не будет

куда "вряд ли" влезет?

Весь несжатый стрим вряд ли влезет, это обычно терабайты. А если блоки стандартные 128к или больше, думаю ощутимой разницы не будет

Друзья, приветствую вас. Я очень ценю скорость, с которой можно получить список файлов в директории при использовании конфигурации ZFS + мета-устройства на отдельном SSD-диске. Из-за политических причин мне необходимо найти альтернативу таковым возможностям ZFS. Пожалуйста, помогите мне рекомендацией: существует ли что-то сопоставимое по скорости (в частности, при получении списка файлов) на других файловых системах? Мое глубокое признание и благодарность будут распространяться настолько, насколько дозволяет разум, без каких-либо излишеств или ограничений, разумеется.

Небось файлов в директории >1М

ну порядок такой, да. я тут вычитал что в xfs можно выносить мету на отдельный девайс и получится что то типа такого же как zfs + meta, но инфы чет пипец мало, вычитал что данные будут писаться на realtime раздел а мета на другой, но очень очень всё мутно

А вам нужен просто список имен или именно с метой?

Bcachefs можно попробовать, можно xfs с метой на ссд проверить.

Вы написали "компрессия поблочно хуже компресси всего несжатого стрима". Т.е. считаете, что стрим ВЕСЬ сожмется разом? Тогда придется его весь поместить в ОП и потом только сжимать. Но так ведь не будет. Через конвеер zstd будет принимать порциями, сжимать и отправлять далее. Я много экспериментировал с zstd - изменял размер окна для сжатия, пробовал тренировать и потом сжимать по словарю и т.д. Уровень сжатия это почти не меняло, иногда даже хуже становилось. Единственно, могло ускорить процентов на 10% процесс компрессии

zstd весь стрим сожмет так же как и если его в файл засунуть. в пределах окна которое явно больше размера блока и кот. можно до 2 гигов сделать

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

как-то неинформативно. понятно, вы ищите drop-in-place замену, но нетривиальные задачи редко так решаются.