Станислав
А ZFS?
Станислав
Превратиться в кашу или откатит транзакцию?
Vladislav
Может всё же речь про то, что мета по умолчанию на 1 девайс пишется 2 копиями?
у меня нет идей, может быть, что по этой причине ZFS выживает гавно ссд
Vladislav
Я не находил каких-то пруфов, что ZFS умирает от гавно ССД
Vladislav
Как и обратного
Станислав
Я думаю, что в btrfs данные тоже должны выживать, т.к. она cow. Но с её логикой работы я слабо знаком
Станислав
Я не находил каких-то пруфов, что ZFS умирает от гавно ССД
Это единственный минус, что я больше не работаю в компании с обслуживанием 10тыс машин) Была у нас идея на 1% аппаратов zfs заюзать) В самых жестких условиях, так сказать
Станислав
на 90% аппаратов были noname SSD, некоторые из них работали хуже hdd 2.5" 2006 года
Vladislav
@socketpair
Vladislav
Видимо нет
Vladislav
Ладно
Vladislav
Станислав
Mark ☢️
Видимо нет
Я здесь
Mark ☢️
Чо ннада
Mark ☢️
А на практике. Чуть-чуть пяка в данных и вся фс в труху
Mark ☢️
В такую же труху
Mark ☢️
Восстановить чем-то можно?
Да, можно. Полным перебором байтов
Mark ☢️
Кароч я не смог в 2 еейсах
Станислав
Жестко
Mark ☢️
Бтрфсцк ниале, маунт тоже ниале
Mark ☢️
И всё
Mark ☢️
Кирпич
Станислав
Кирпич
Спасибо за инфу, не даром я её не люблю
Mark ☢️
Аффтары кукарекают что мол все можно восстановить. Но мне не удалось
Mark ☢️
Причем не некоторые файлы, а вся ФС
Mark ☢️
Спасибо за инфу, не даром я её не люблю
Но! У нас много бутеров. И если диск не говно, то то оно таки нихрена не падает даже под адовой нагрузкой
Vladislav
Поэтому да, диск для любой ФС не должен быть гавно
Станислав
Поэтому да, диск для любой ФС не должен быть гавно
В принципе 840,850,860 evo и pro не подводили ни разу меня, но без PLP всё равно гарантий нет
Mark ☢️
Они fsync не игнорят насколько я помню
Прекол когда очередь на запись большая или на прочистку FTL. И именно тогда происходит вырубание
Mark ☢️
Тогда кондеров не хватает и превед
Free
Ну вот приедут все заказанные диски - попробую сливать. А пока развивается следующим образом: Попробовал, выключив север, убрать возможную проблему контактов: переприсоединил 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 Нагуглил, что это обычное дело - превышение оценки по сравнению с реальным объемом данных Правда, объясняют это дедупликацией, которой у меня совсем нет ...
Free
Сжатие включено?
Да. Но ведь он же не разжимает во время отправки, от этого передаваемый объем не должен меняться?
Nikolay
А, значит, разжимает?
разжимает. с опцией -c не будет разжимать
Free
Странно: вот сейчас передал 777ГБ, и в новом датасете ровно столько же появилось. То есть как будто не разжимает...
Free
разжимает. с опцией -c не будет разжимать
Попробую для следующего датасета. Сейчас этот сенд не буду трогать.
Nikolay
Странно: вот сейчас передал 777ГБ, и в новом датасете ровно столько же появилось. То есть как будто не разжимает...
скорее всего разжимает, а на приёмнике снова сжимает. Двойная работа. но -с точно уменьшает объём передачи, уже так делал, намного быстрее всё получается
Free
Но ведь он же повторяет на новом полностью датасет исходный. То есть и размер блока со старого переносит, и компрессию оставляет ту же, что была в исходном. Тогда зачем ему разжимать и на другой стороне сжимать?
Vladislav
Но ведь он же повторяет на новом полностью датасет исходный. То есть и размер блока со старого переносит, и компрессию оставляет ту же, что была в исходном. Тогда зачем ему разжимать и на другой стороне сжимать?
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 тогда может и лучше понасжимать (сэкономить трафик)
Станислав
а еще можно пропускать разжатый стрим через zstd -zc ... zstd -dc тогда может и лучше понасжимать (сэкономить трафик)
Это будет полезно только в случае, когда нужно применить другое сжатие на новом месте. Или же это был сарказм?))
Станислав
Или если исходный без компрессии
Mark ☢️
Сделайте кто-нибудь нормальный бенч бутер вс зфс в разных сценариях. Эскулайт, кекхаус, поцгрес, распаковка исходников ведра, поиск в них грепом
Roman
кх нет смысла тестить на бтрфс и зфс.
Δαρθ
Или если исходный без компрессии
очевидно что компрессия поблочно хуже компресси всего несжатого стрима
Δαρθ
кх нет смысла тестить на бтрфс и зфс.
есть. бтрфс быстрее может оказаться )
Roman
разве что для этого, да)
Станислав
очевидно что компрессия поблочно хуже компресси всего несжатого стрима
Весь несжатый стрим вряд ли влезет, это обычно терабайты. А если блоки стандартные 128к или больше, думаю ощутимой разницы не будет
Станислав
куда "вряд ли" влезет?
Вы написали "компрессия поблочно хуже компресси всего несжатого стрима". Т.е. считаете, что стрим ВЕСЬ сожмется разом? Тогда придется его весь поместить в ОП и потом только сжимать. Но так ведь не будет. Через конвеер zstd будет принимать порциями, сжимать и отправлять далее. Я много экспериментировал с zstd - изменял размер окна для сжатия, пробовал тренировать и потом сжимать по словарю и т.д. Уровень сжатия это почти не меняло, иногда даже хуже становилось. Единственно, могло ускорить процентов на 10% процесс компрессии
Станислав
И то, 10% это в исключительном случае.
Станислав
Весь несжатый стрим вряд ли влезет, это обычно терабайты. А если блоки стандартные 128к или больше, думаю ощутимой разницы не будет
Соврал, я то проверял на блоке 1M. Но всё равно разница 3.5% при блоке 128к в датасете и дефолтных 128M при использовании zstd -c : root@pc:/ext/noZSTD# zfs get compression,recordsize rpool/ext/noZSTD rpool/ext/ZSTD rpool/ext/ZSTD1M NAME PROPERTY VALUE SOURCE rpool/ext/noZSTD compression off local rpool/ext/noZSTD recordsize 128K default rpool/ext/ZSTD compression zstd inherited from rpool rpool/ext/ZSTD recordsize 128K default rpool/ext/ZSTD1M compression zstd inherited from rpool rpool/ext/ZSTD1M recordsize 1M local root@pc:/ext# du -h *ZSTD*/* 511M noZSTD/07 - Tiny Dancer.dsf 353M noZSTD/07 - Tiny Dancer.dsf.zst 368M ZSTD/07 - Tiny Dancer.dsf 355M ZSTD1M/07 - Tiny Dancer.dsf
Станислав
А уже при блоке 1M в датасете можно пренебречь
Vladislav
Поделитесь ссылкой на ваш любимый скрипт рекурсивного отката zfs разделов на конкретный снимок?
Алексей
Друзья, приветствую вас. Я очень ценю скорость, с которой можно получить список файлов в директории при использовании конфигурации ZFS + мета-устройства на отдельном SSD-диске. Из-за политических причин мне необходимо найти альтернативу таковым возможностям ZFS. Пожалуйста, помогите мне рекомендацией: существует ли что-то сопоставимое по скорости (в частности, при получении списка файлов) на других файловых системах? Мое глубокое признание и благодарность будут распространяться настолько, насколько дозволяет разум, без каких-либо излишеств или ограничений, разумеется.
Vladislav
Небось файлов в директории >1М
Алексей
Небось файлов в директории >1М
ну порядок такой, да. я тут вычитал что в xfs можно выносить мету на отдельный девайс и получится что то типа такого же как zfs + meta, но инфы чет пипец мало, вычитал что данные будут писаться на realtime раздел а мета на другой, но очень очень всё мутно
Алексей
А вам нужен просто список имен или именно с метой?
мне нужно чтобы листинг файлов в директории проходил быстро, в зфс к этому еще подключается и подсчет места, т.е. все что нужно знать о файле хранится на ссд и это всё очень быстро работает не нагружая хард. вот это мне и нужно