Алексей
что то смущает?
Действительно чат же про хфс
riv
Ахаха, чат стал xfs😂
Vladislav
Недотягивает
Ivan
Ахаха, чат стал xfs😂
Илон и zfs купил
Konstantin
Как уменьшить ulimit в xfs?😺
A1EF
Действительно чат же про хфс
Ого, а я думал, про NTFS! Посоветуйте тогда чат по FAT32 :D
A1EF
Я ЗНАЛ!
Ivan
https://t.me/btrfs_chat
это точно не пониме чат ?
Fedor
беспроигрышный вариант данные никогда не теряются, даже при форматировании
Ivan
самое время вспомнить про pifs
Fedor
отсутствие фрагментации
Fedor
ггг
Nikita
Перенести данные на ZFS
пусть там пропадают 😁
Станислав
пусть там пропадают 😁
Шутки шутками, но как не крути, а шансов потерять на ZFS всё равно меньше, если по уму собрать
central
а потом у них сгорел датацентр вместе с бекапами
Станислав
а потом у них сгорел датацентр вместе с бекапами
Это не отменяет того, что шансов меньше. К тому же ни для кого не секрет, что бекапы должны быть разнесены территориально, притом лучше не в одном регионе. А то налетит цунами и даже данные в разных ДЦ затопит и 100Тб фото с котиками ушли в небытие
synapse
а потом у них сгорел датацентр вместе с бекапами
это потому что у них в тимплейтах которые ставятся вместо zfs - mdadm везде сделан )
Ivan
это потому что у них в тимплейтах которые ставятся вместо zfs - mdadm везде сделан )
помнится у них предлагались весьма всратые сетапы. например нужен сервер с ссд. вот тебе на выбор сервер с одним ссд на 120 гигов, либо же вот тебе на 3 по 500. два по 500 ну никак нельзя.
synapse
Никогда не юзал темплейты
Раньше квм денег прям стоил
Georg🎞️🎥
Илья
Коллеги, ковырялся в коде ZFS, и выяснил что это пофакту FAT16 на стеройдах. Начал копаться в коде, и походу один из разработчиков ORACLE забыл стереть комментарий. Походу когдато давным давно его форкнули и начали развивать как ZFS
Ivan
Коллеги, ковырялся в коде ZFS, и выяснил что это пофакту FAT16 на стеройдах. Начал копаться в коде, и походу один из разработчиков ORACLE забыл стереть комментарий. Походу когдато давным давно его форкнули и начали развивать как ZFS
Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я вполне понимаю, что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых – стоп. Остальных просто не найдут.
Fedor
получается zfs можно конвертировать в exfat
Ivan
обратную совместимость сломали
Nikita
теперь только в extzfs
exopenzfs... хотя, зависит от того, какие вы features использовали.
Илья
Нифига не сломали, пустой свеже созданный пул без датасетов и вволов , легко конверитует в exFAT обычным хекс редактором
Илья
Да
central
/report
Group Butler
/report
Reported to 1 admin(s)
Ivan
/report
чет в удаленных не видно спама
Fedor
а, боты научились удалять сообщения, при этом оставаясь в группе
central
аккаунт александра без ника был
Fedor
те как это zfs
Nikita
я не буду за это платить!
Sergio
/report
central
/report
Group Butler
/report
Reported to 1 admin(s)
Group Butler
Hi Вячеслав!
The Join Captcha Bot
Капча решена, Пользователь подтвержден. Добро пожаловать в чат, @psychik
Δαρθ
Ну вот опять. Сидел считал хеши (rhash -r) на файлопомойках и их копиях. ZFS на raid1, на быстрых дисках, копия на btrfs на медленном. Размеры помоек больше чем ОЗУ. Если в помойке были только длинные файлы (сотни мб-гигабайты) то ZFS уверенно выигрывает по скорости вычитки. Если куча мелких файлов -- отстаёт. Если и то и то -- примерно наравне с btrfs.
Nikita
/report
Group Butler
/report
Reported to 1 admin(s)
riv
а не должны?
Это был риторический вопрос призванный обратить внимание на надёжность. Сравнивалось несравнимое.
riv
ага. недавно как раз мне zfs файлы зануляло
Давайте подробности. Я такие случаи коллекционирую (чтобы знать как не надо)
Vladislav
Давайте подробности. Я такие случаи коллекционирую (чтобы знать как не надо)
Товарищ делал отправку снепшотов через машину (т.е. 1 машина --> 2 машина --> 3 машина) где все версии zfs разные
riv
Вопрос знатокам btrfs: в zfs мне очень не хватает того, что бы я назвал reverse incremental snapshot receive; представьте, что у вас есть основной zfs и вы делаете сники и пересылаете их на backup-сервер, оставляя на источнике один последний снимок. А теперь вам нужно восстановить один из давно переданных снимков с backup-сервера. Но вы не можете принимать более старый снимок не удаляя более новый. Вопрос: в btrfs это возможно?
Aleks
а зачем новый снимок, если хочешь восстановить старый?
Fedor
Или в какой-нибудь профильный чат
riv
а зачем новый снимок, если хочешь восстановить старый?
Поясняю по ситуации с zfs. У вас есть прод, там что-то пишется, вы это снепшотите, затем отправляется инкрементально в бекап. Цепочка снимков должна непрерывно передаваться в бекап, чтобы не отправлять туда датасет целиком. Представьте что вы бакапите виртуалку суммарным объемом 100ТБ и отправляете в бекап по каналу 300 мегабит, например. Вы же не захотите все 100ТБ передавать каждый раз, а инкрементов у вас, например всего 50ГБ в день. Теперь что-то навернулось и вам нужен бекап на проде, как его получить? с zfs у вас один вариант - тянуть все 100ТБ, чтобы восстановить копию. Если бы можно было отправить разницу между бекапным снимком и самым новым (т.е. не новый - старый, а старый - новый) и принять её на в датасет на проде так чтобы там просто снова появился удаленный старый снимок, то вы бы могли клонировать этот восстановленный снимок и что-то с клоном поделать, например виртуалку запустить. Не надо мне предлагать восстановить на бекапном сервере. Часто бывает так что запустить то что забекапилось на бекапный сервер просто не возможно там, надо много ресурсов, которые есть на проде. Не знаю понятно ли объяснил? А может быть такое есть в zfs и я просто не вкурсе? И к моему удивлению такого функционала нет и нигде даже не упоминается что он был бы полезен.
Aleks
а смонтировать снимок и слить нужные данные не вариант?
Vladislav
Поясняю по ситуации с zfs. У вас есть прод, там что-то пишется, вы это снепшотите, затем отправляется инкрементально в бекап. Цепочка снимков должна непрерывно передаваться в бекап, чтобы не отправлять туда датасет целиком. Представьте что вы бакапите виртуалку суммарным объемом 100ТБ и отправляете в бекап по каналу 300 мегабит, например. Вы же не захотите все 100ТБ передавать каждый раз, а инкрементов у вас, например всего 50ГБ в день. Теперь что-то навернулось и вам нужен бекап на проде, как его получить? с zfs у вас один вариант - тянуть все 100ТБ, чтобы восстановить копию. Если бы можно было отправить разницу между бекапным снимком и самым новым (т.е. не новый - старый, а старый - новый) и принять её на в датасет на проде так чтобы там просто снова появился удаленный старый снимок, то вы бы могли клонировать этот восстановленный снимок и что-то с клоном поделать, например виртуалку запустить. Не надо мне предлагать восстановить на бекапном сервере. Часто бывает так что запустить то что забекапилось на бекапный сервер просто не возможно там, надо много ресурсов, которые есть на проде. Не знаю понятно ли объяснил? А может быть такое есть в zfs и я просто не вкурсе? И к моему удивлению такого функционала нет и нигде даже не упоминается что он был бы полезен.
Разверни veeam и прекрати ебать мозг
Vladislav
А veeam умеет zfs?
Он умеет бэкапить любую шару и, через агента, любую фс
riv
Разверни veeam и прекрати ебать мозг
Производительность низкая, решение закрытое. Может мне ещё и гиперви поставить?
Vladislav
Vladislav
Тут вроде уже поднимали тему бэкапов ZFS sanoid zfs_autobackup
riv
Зато поддерживает требования которые ты выдвигаешь?
Вопрос был про zfs в контексте сравнение zfs и btrfs. Причем тут веем вообще? Есть ещё требование к удовлетворительной производительности. У веем производительность для моего случая не удовлетворительная, требовпние к ресурсам выше, внедрение жороже и всё в целом хуже. И как веем поможет в инкрементальном восстановлении снимка? Там есть такой функционал? Скорее всего нету, он скорее всего может откатить весь прод к точке бекапа, а этого не нужно.
Vladislav
А нет, вру, файловый не поддерживает Reverse Incremental
Vladislav
Тогда да, если нужно бэкапить ZFS шару таким образом, то F
riv
Тут вроде уже поднимали тему бэкапов ZFS sanoid zfs_autobackup
Да само собой так и делается. Речь не о бекапе. Zgs оптимален для бекапа. Речь о небольшой недоработке функционала утилиты zfs-receive, а именно, не возможности принять с бекапа старый снимок в инкрементальном режиме. А это было бы очень полезно. И раз уж решь зашла про соавнение с btrfs я поинтересовался, в контексте соавнения с zfs, нет ли там такого. Ещё раз попробую объяснить. Речь идет о возможности сделать инкрементальную пересвлку не новый минус старый, а наоборот, старый минус новый, т.е. вернуть старый снимок и необходимые доя его существования блоки, когда в целевом датасете есть более новый но уже переданеый в бекап снимок. Нужно это чтобы клонировать сатрый снимок в целях получения доступа к бекапу не на бекапном сервере, а на основном. Речь идет о случае с гиганскими датасетами: 10ТБ, 100ТБ которые бекапятся ингрементально через узкий канал, условноо 300мегабит.
Vladislav
Да само собой так и делается. Речь не о бекапе. Zgs оптимален для бекапа. Речь о небольшой недоработке функционала утилиты zfs-receive, а именно, не возможности принять с бекапа старый снимок в инкрементальном режиме. А это было бы очень полезно. И раз уж решь зашла про соавнение с btrfs я поинтересовался, в контексте соавнения с zfs, нет ли там такого. Ещё раз попробую объяснить. Речь идет о возможности сделать инкрементальную пересвлку не новый минус старый, а наоборот, старый минус новый, т.е. вернуть старый снимок и необходимые доя его существования блоки, когда в целевом датасете есть более новый но уже переданеый в бекап снимок. Нужно это чтобы клонировать сатрый снимок в целях получения доступа к бекапу не на бекапном сервере, а на основном. Речь идет о случае с гиганскими датасетами: 10ТБ, 100ТБ которые бекапятся ингрементально через узкий канал, условноо 300мегабит.
Спасибо, я знаком с принципом работы Reverse Incremental
Vladislav
Он прекрасно описан у Вима
riv
? Он восстановит файлы нужной версионности
Вы просто не вникли, восстанавливать 100ТБ безумие, а клонировать снимок в zfs почти бесплатно по ресурсам