LINUX.ORG.RU

ZFSv28 портирована в ветку FreeBSD 8

 ,


0

1

Сегодня ZFSv28 портирована в ветку FreeBSD 8.

Пользователям стабильной 8.2 версии FreeBSD стали доступны такие фичи ZFS, как:

  • Дедупликация — обнаружение на уровне файловой системы дубликатов блоков и сохранение только одной копии с восстановлением целостности различных файлов, содержащих этот блок, на лету. Экономит место на дисках в операционной среде jail'ов, располагающихся в одном пуле.
  • RAIDZ3, вариант RAIDZ с хранением трех копий отвечающих за обеспечение целостности структур, что позволяет значительно повысить надежность хранения по сравнению с RAID-режимами с двойным дублированием — RAID-6 и RAIDZ2.
  • Утилита «zfs diff», позволяющая просмотреть список изменений между двумя ZFS-снапшотами или между снапшотом и текущим состоянием ФС. Утилита отображает журнал изменений, переименований, создания и удаления файлов и каталогов.
  • Команда «zpool split» для разделения отзеркалированного пула на несколько независимых пулов, минуя промежуточные операции клонирования.
  • Счётчик ссылок на снапшот для защиты снапшотов от ошибочного удаления.
  • Команда «zpool import -F», позволяющей перемотать поврежденный пул к состоянию, соответствующему более ранней группе транзакций, что позволяет с высокой вероятностью восстановить повреждённый пул из состояния FAILED.
  • Импорт пула в режиме только для чтения.
  • Оптимизации и тюнинг общей части подсистемы ZFS в FreeBSD.

>>> Подробности

★★★★★

Проверено: JB ()

Ответ на: комментарий от unC0Rr

хранение файлов в общем случае - то простая задача.

В случае моего десктопа - очень простая.

ZFS - слишком сложное решение для этого.

takino ★★★★★
()
Ответ на: комментарий от takino

у меня не тормозит даже на винде.

//и да, недавно гонял в nexuiz параллельно с обновлениями генты. load average. Все отлично.

devl547 ★★★★★
()
Ответ на: комментарий от takino

> хранение файлов в общем случае - то простая задача.

Уверен?

В случае моего десктопа - очень простая.

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

А ты пойди сотню-другую терабайт сохрани, тогда и посмотрим.

ZFS - слишком сложное решение для этого.

А мужики то и не знают.

anonymous
()
Ответ на: комментарий от ziggi

загляните наконец-то в сам код - глянуть религия не позволяет?

Позволяет, но смысла нет. Я верю вам на слово.

Ximen ★★★★
()
Ответ на: комментарий от robot12

> Интересно, как бздуны решили вопрос о лицензировании deduplication.

А чего там собственно решать? Код открыт, лицензия позволяет.

anonymous
()
Ответ на: комментарий от anonymous

>> хранение файлов в общем случае - то простая задача.

Уверен?

В случае моего десктопа - очень простая.

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

А ты пойди сотню-другую терабайт сохрани, тогда и посмотрим.

Именно поэтому на десктопе PC-BSD с UFS+SUJ и ZFS RAIDZ на FreeNAS в кладовке. Одно другому не машает.

PS Снепшотами при обновлениях системы / софта не пользуюсь.

anonymous
()
Ответ на: комментарий от ziggi

>Про BSD rip читаю 15 лет. Уже даже не смешно - поколения меняются, глупость та же.

+100500. Местами даже раздражает

Pinkbyte ★★★★★
()
Ответ на: комментарий от takino

> Кстати: пользую UFS.

Рад за тебя.

Потому что простота превыше всего.

Что является критерием простоты?

А то тут красноглазики усирались, что ZFS - это монструозный-комбайн-все-в-одном, что мол там херова уйма ненужного кода, который только занимает место в ОЗУ, а как сравнили количество строк кода в реализациях ZFS и связки LVM+FS, оказалось, что все не так очевидно.. А при моде использовать на каждый чих свою FS так и вообще :)

Чем сложнее система - особенно созданная для выполнения простых задач

Это хранение данных то простая задача? Может на десктопе отдельно взятого айтишника она и простая. А если взять масштабы побольше? Тут вот ребята нехилый бенефит поимели: http://twitter.com/#!/NexentaEMEA/status/58858139356901376

Еще бы - 2PB+ сохранили в 6TB. Может пойдешь их за простую UFS поагитируешь, а заодно бабла на решение подобного масштаба на UFS подкинешь?

- тем выше риск того, что по пути она сломается и перестанет работать. ZFS - типичный тому пример.

Интересно, что ты хотел сказать этим заявлением? Что UFS не ломается по пути? Зачем же тогда fsck, если она такая простая и не ломается?

Или ты что-то другое имел ввиду? Поясни. Можно с примерами, чтобы не выглядеть голословным.

anonymous
()
Ответ на: комментарий от Ximen

Ну? Развивай мысль.

> Неужели, там, где оно действительно надо, используют фряху?

там где Яндексу оно действительно надо, как раз таки используют фряху.

uin ★★★
()
Ответ на: комментарий от takino

>Анонимус как всегда вякнул аггрессивно из-под стола.

Помилуйте, где ж агресивно то? Или Вы не согласны с тем что серебряной пули нет? На среднестатистическом десктопе UFS+SUJ за глаза. А если Вас интересует NAS или просто нужно хранить большие обьемы и если Вам ДЕЙСТВИТЕЛЬНО нужны плюшки zfs- тогда да. Часто zfs вменяемой альтернативы нету. Где я не прав?

anonymous
()

поздравляю фришников!!!

Zlo ★★★★★
()
Ответ на: комментарий от Ximen

> Серьёзно? У Яндекса стораж на фряхе с zfs?

без понятия...

знаю только что поисковая система на сервере под FreeBSD крутится.

uin ★★★
()
Ответ на: комментарий от takino

ну да я тоже в песочнице экскаватором куличики не строил.. но скажи ты на стройку с ведёрком и пластиковой лопатой пойдёшь?

Thero ★★★★★
()

Я вообще думаю, что Korn shell самый быстрый shell. Быстрее питона точно.

PymOxim
()
Ответ на: комментарий от anonymous

Я говорил про _СВОЮ_ ситуацию и свои нужды.

Сложна ZFS наличием нехилой такой тонны лишнего мне функционала.

takino ★★★★★
()
Ответ на: комментарий от anonymous

Там, где я говорил про себя, а не про планетарный масштаб.

takino ★★★★★
()
Ответ на: комментарий от takino

> Сложна ZFS наличием нехилой такой тонны лишнего мне функционала.

Ааа.. Ну с тобой все ясно. Может, стоит выкинуть контупер в окно и к абаку вернуться?

anonymous
()
Ответ на: комментарий от takino

> Что за дурацкая мода: растягивание частного случая на общие километры?

Чья бы корова мычала

anonymous
()
Ответ на: комментарий от anonymous

Не умеешь читать и внятно говорить - можешь мычать дальше, аки твоя корова. :)

takino ★★★★★
()

Поздравляю всех неравнодушных!

xspirit
()
Ответ на: комментарий от anonymous

Зачем?

Затем, что юзать в продакшн fs без каких-либо вариантов действий при аварийной ситуации я не хочу и не буду. Понятно, что backup/restore есть всегда, однако

1) Тупой и примитивный он лишает меня гибкости
2) Backup на какой-то fs хранить надо, потому что современные объемы данных никак не располагают к их хранению на dvd/bd/стримере

zgen ★★★★★
()
Ответ на: комментарий от zgen

> Затем, что юзать в продакшн fs без каких-либо вариантов действий при аварийной ситуации я не хочу и не буду.

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

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

mukoh
()
Ответ на: комментарий от mukoh

проектировать свою систему так, чтобы минимизировать количество точек отказа?

Минимизировать != исключить

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

Да, но дело в том, что в случае аварии на v28 был вариант только разбора вручную (код fs, диск, выколупывание данных [здравствуй diskedit]). Теперь же можно принудительно импортировать и попробовать что-то достать, а само собой не продолжать работать.

zgen ★★★★★
()
Ответ на: комментарий от zgen

>> проектировать свою систему так, чтобы минимизировать количество точек отказа?

Минимизировать != исключить

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

Просто не раз наблюдал, как люди берут и лепят из чего есть хранилище, надеясь, что ZFS сделает все волшебно, а потом приходит северный пушной зверек и начинает выясняться всякая интересная всячина - что ожидается, что все будет работать, даже если железный лом кинуть, а оказывается нифига, избыточности нет, или она кончилась, потому что никто не следил, за тем, как там диски поживают, или LUN'ы, из которых собран пул, нифига не независимые, или чего-нибудь.

Теперь же можно принудительно импортировать и попробовать что-то достать, а само собой не продолжать работать.

Я тебя разочарую - здесь -F не означает «очень принудительно импортировать», а означает «если с последней txg не открывается, попытаться использовать предыдущие две, вдруг получится». Но это не единственный возможный сценарий отказа, хотя и довольно распространенный, из-за стремления чтоб было быстро любой ценой. Если диск действительно очередность записи малость попутал (ну или cache flush проигнорировал), то поможет. Может быть. А может быть и нет.

По мне так лучше правильно систему изначально строить, нежели на то, что теперь -F есть закладываться. Хотя, эта возможность конечно тоже не помешает.

mukoh
()
Ответ на: комментарий от mukoh

Просто не раз наблюдал

Прописные истины мне не нужны, спасибо!

Но это не единственный возможный сценарий отказа

Спасибо, Капитан!

По мне так лучше правильно систему изначально строить

Еще раз спасибо!

Еще раз, для тех, кто не понял с первого - наличие -F лучше, чем его отсутствие. Так же, как наличие fsck для ext* лучше, чем его отсутствие, хотя и, как вы правильно, Капитан, заметили fsck тоже «может поможет, а может и нет». Может даже угробит всё окончательно.

Ну так давайте откажемся от fsck - ну нафига он, а ВДРУГ не поможет? Ну вы же всегда можете открыть исходники ext и взять dd в руки, правда? O_o

zgen ★★★★★
()
Ответ на: комментарий от zgen

> Еще раз, для тех, кто не понял с первого - наличие -F лучше, чем его отсутствие.

А вот это что такое:

Хотя, эта возможность конечно тоже не помешает.

Или сэр не читал, а сразу за клаву схватился, писать про капитана очевидность?

Так некоторым очевидные вещи надо не один раз повторять, пока дойдет вся очевидность. Если тебе не надо - ну извини, тем лучше для тебя.

Ну так давайте откажемся от fsck

А это было бы на самом деле не так уж и плохо :) Во всяком случае, это заставляло бы разработчиков более тщательно относится к проектированию, разработке и тестированию на всех этапах жизненного цикла ФС. А имея fsck очень легко поддаться соблазну расслабиться - ведь есть же fsck, вдруг да починит.

mukoh
()
Ответ на: комментарий от mukoh

Или сэр не читал, а сразу за клаву схватился, писать про капитана очевидность?

Нет, я читал, но так и не понял, нафига вы написали кучу текста, если вам "-F не мешает". Вам «не мешает наличие», а мне «мешает отсутствие». Что-то еще непонятно?

А это было бы на самом деле не так уж и плохо :)

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

zfs предоставляет только check целостности данных. Я могу 10, 20 и 100 раз «следить за» дисками, lun'ами, но оно НЕИЗБЕЖНО «накроется». И я неизбежно встану перед вопросом restore from backup + «zpool -F» или просто restore from backup.

Если вам это непонятно, то нам с вами говорить не о чем, ибо вопрос был «зачем мне -F» -

Затем, что мне работать надо, а не понукать разработчиков, чтобы они «тщательно относились». И работать в продакшн я буду только с той fs, у которой есть запасные варианты действий при аварийных ситуациях.

zgen ★★★★★
()
Ответ на: комментарий от anonymous

В том то и дело что условия никому кроме как участникам не известны.

robot12 ★★★★★
()

zfs, это софтраид на новом витке развития. Плохо ли, хорошо ли, но это все побочный эффект повального нищебродства корпораций.

AVL2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.