Eugen
Scstadm - -list_target
Это просто список таргетов, я имею в виду связь таргет-инициатор, что бы понимать кто с чем работает. Просто там не нашел внятного ничего
nikolay
Scstadm - -config
nikolay
Должен вывести полную текущую конфигурацию
star
доброй всем)
star
подскажите, что вообще закое этот ваш зфс?
star
чем он отличается от рейда, и бтрфс?
central
чем он отличается от рейда, и бтрфс?
Смешались кони люди, это вообще разные понятия
Vladislav
Мне кстати интересно. Почему называют CoW, если поведение ZFS это RoW? "новый вариант блока запишется в новое место, не затирая старый."
Vladislav
А при CoW новый блок пишется на место старого, а старый копируется в новое место
Vladislav
Vladislav
Или у CoW есть другое определение?
George
Мне кстати интересно. Почему называют CoW, если поведение ZFS это RoW? "новый вариант блока запишется в новое место, не затирая старый."
https://en.wikipedia.org/wiki/Copy-on-write When implementing snapshots, there are two techniques: Redirect-on-write or ROW: the original storage is never modified. When a write request is made, it is redirected away from the original data into a new storage area. Copy-on-write or COW: when a write request is made, the data are copied into a new storage area, and then the original data are modified. Despite their names, copy-on-write usually refers to the first technique. COW does two data writes compared to ROW's one; it is difficult to implement efficiently and thus used infrequently.
George
Это мой скриншот, спасибо
хех, не посмотрел его, да) в общем устовяшееся
Vladislav
собственно мне и стало интересно, просто потому что так сложилось или может есть более очевидный фактор почему
George
но вообще т.к. Copy-on-write не говорит о том что куда копируется и с чем дальше работают, сам термин немного размыт, потому (субъективно) он и стал общим, когда в принципе происходит не просто in-place изменение
Vladislav
Просто в ZFS нет как таковой операции копирования данных при записи. Просто метаданные начинают ссылаться на новой блок Я ведь правильно понимаю?
George
https://habr.com/ru/company/vk/blog/529516/
мне на это статью в личку даже про это кто-то пытался вразумляющее написать про CoW
George
Просто в ZFS нет как таковой операции копирования данных при записи. Просто метаданные начинают ссылаться на новой блок Я ведь правильно понимаю?
ну если блок менялся не полностью, то будет и часть копирования, потому про неоднозначность термина и говорю
Vladislav
Я думал максимальная атомарность это как раз размер блока
George
Я думал максимальная атомарность это как раз размер блока
ага, но если в блоке 4КБ поменять 1 байт, то оставшиеся 4095 байт тоже должны быть записаны в новый блок, т.е. скопированы
Vladislav
Я считал что с точки зрения вышестоящего уровня все данные блока всё равно передаются. Т.е. если рассматривать ZFS как бэкэнд для iSCSI\ФС
Vladislav
но да, это скорее частный случай применения
Vladislav
скорее всего и снимки скачивает
Art
ага, но если в блоке 4КБ поменять 1 байт, то оставшиеся 4095 байт тоже должны быть записаны в новый блок, т.е. скопированы
Геоогий, а в теории возможно ли, что когда-нибудь ЗФС позволит кататься по снимкам в любом порядке? То есть откатился такой на позапрошлый снимок, затем вообще на самый первый, и потом уже на самый последний - и все снимки остались на своих местах, не удалились. Или же такое в корне невозможно?
Александр
Ты не сможешь сделать инкрементальный send "через голову" того, что на бэкапе
Александр
zfs destroy
Александр
Так не создавай ненужных снапшотов
Александр
Тогда не удаляй на исходном сервере самые новые снапшоты
Александр
Вот смотри. У тебя на двух серверах снапшоты 1, 2, 3, 4, 5. Ты можешь удалить на оригинале 1-4, создать 6, сделать инкрементный бэкап 5 -> 6
Александр
А если ты удалишь на оригинале 5, то тебе и на бэкапе нужно будет удалить 5
Александр
нет, на бэкапе они удалятся не раньше, чем ты их там явно удалишь
Александр
Причем можно на одном удалить 1 и 3, на другом 2 и 4 и никаких проблем
Александр
Снапшоты не имеют между собой никакой мистической связи.
Александр
Если ты сендишь -R без -I, то снапшотов на бэкапе НЕ ДОЛЖНО БЫТЬ. Если с -I, то последним снапшотом на бэкапе должен быть тот, от которого ты инкрементишь
Александр
Что было до того общего снапшота, с которого идет инкремент, не волнует вообще никого
Александр
Но в целом правило - никогда не создавай снапшотов на бэкапном датасете. И вообще - ничего на него не пиши, монтируй только readonly
Александр
а лучше клонируй
Александр
сделай откат на самый новый снапшот
Art
zfs clone, zfs rename, zfs promote
Это-то я знаю) Но хочется как у qcow2 или vmdk историю снимков, когда нет ограничений в перемещении по ним
Ilya
Это-то я знаю) Но хочется как у qcow2 или vmdk историю снимков, когда нет ограничений в перемещении по ним
там снимок - это RW-дельта относительно основных данных, а здесь снимок - это RO-дерево айнод
Александр
zfs set readonly=on. RTFM
Александр
Документация - рулез
Александр
man zfs-set
Anonymous
Nice to meet you
Александр
Сюрпрайз! - закричала документация.
Георгий
Коллеги, на сколько актуально данное сравнение для текущей версии зфс? https://habr.com/ru/post/344204/ Интрересует raid10 и его zfs аналог
George
Коллеги, на сколько актуально данное сравнение для текущей версии зфс? https://habr.com/ru/post/344204/ Интрересует raid10 и его zfs аналог
8 декабря 2017 емнип за 5 лет точно были улучшения, стоит смотреть changelogs, или проще - считать сравнение устаревшим по умолчанию
George
т.к. на стороне mdadm тоже можно что-то меняться
Георгий
Есть возможность сравнить сейчас, на актуальной версии, методику тестирования можно оставить ту же? Или чтото заменить в параметрах fio?
Evgenii
тесты сферического коня в вакууме всегда будут против ZFS, когда реальная производитьность может быть выше. — все потому, что ZFS очень сложная, перед записью новой группы транзакций она должна сделать уйму вычислений. — из за этого коммит данных на диск происходит 2 раза. (чтобы снизить latency между фс и приложением) 1) записываются raw данные - это лог 2) записываются транзакции zfs — это приводит к Амплификации записи. Когда вместо записи 1мб, нужно записать 2 мб, или вместо 400 IOPS, нужно потратить 800 IOPS — ситуация схожа с реляционными базами Однако в ZFS так же есть ряд встроенных механизмов, чтобы обойти эти ограничения и даже стать быстрее любой классчической фс
Evgenii
Если вам не нужны функции ZFS, не используйте ее. Потому, что это усложнение, в котором все равно придется разбираться!
Anonymous
Добрый вечер. Решил попробовать линукс так как собираюсь дальше развиваться в сфере программирования и линукс везде пригодится. Ситуация такая: у меня есть внешний ссд 120гб и я хочу туда установить линукс и пользоваться когда понадобится. Но проблема в том что у меня в ноутбуке, точнее в биосе нет раздела где можно изменять основной диск то есть распределить приоритет дисков. Кто может подсказать как можно решить проблему?
inqfen
Подсказываю-обратиться в нужный чат
inqfen
Зфс тут и рядом не при чем
Anonymous
Извиняюсь. Можете дать линк если у вас есть нужный чат.
Δαρθ
Roman
Всем привет, кто какую файловую систему использует в виртуалках linux поверх ZFS на хосте(proxmox)? или без разницы?
Ivan
ntfs 😅
Roman
ну там выбор не велик, поэтому уточнил вопрос)
Roman
к примеру ставим ext3, т.к. нафиг ненужен журнал, или юзаем ext4 с выключенным журналом
Art
Всем привет, кто какую файловую систему использует в виртуалках linux поверх ZFS на хосте(proxmox)? или без разницы?
без разницы, я всё использую, кроме собственно зфс) Её саму в виртуалках не рекомендуюется использовать
Art
Почему?
ну вроде как по тем же причинам, почему не нельзя использовать ЗФС поверх сторонних аппаратных и программных рейдов - ЗФС должна иметь прямой доступ к физическим дискам, а то бобо
Ярослав
Бобо не будет, просто производительность не на все сто
Nikita
Кстати, более-менее в тему вопрос. Кто-то делал тесты/замеры/наблюдения, есть ли разница, отдан под zfs весь диск в сыром виде или сделан отдельный раздел и отдан только он?
Nikita
Я в курсе про то, что при передаче диска целиком от него так или иначе отрезается условный "резерв", да и при замене диска может всплыть расползание размеров на больших объемах, но тем не менее.