oss из портов, а не ядерный
//Главный К.О.

> для выполнения простых задач

ZFS - типичный тому пример.

ZFS вообще-то для сложных задач

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

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

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

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

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

load average ~6. selffix.

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

Уверен?

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

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

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

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

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

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

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

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

Говоришь, словно в линуксе оно есть.

Говорю так, словно в нексенте оно есть.

неужели про Татьяныча на ЛОР -е никто уже не помнит?

Плохо, когда не знаешь, да ещё забудешь.

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

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

http://www.enterprisestorageforum.com/sans/news/article.php/3891426/NetApp-th...

напомню.

программисты NetApp не написали ни строчки кода ZFS. //K.O.

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

Уверен?

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

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

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

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

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

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

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

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

> http://www.enterprisestorageforum.com/sans/news/article.php/3891426/NetApp-th...

напомню.

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

Плохо, когда не знаешь, да ещё забудешь.

Яndex же..

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

Рад за тебя.

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

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

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

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

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

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

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

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

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

Яndex же..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда «zpool import -F»,

Я её ждал!

>>Команда «zpool import -F»,

Я её ждал!

Зачем?

Затем.

> Затем.

Вопрос не тебе был.

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

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

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

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

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

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

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

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

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

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

Словно ей много людей пользуется.

Зачем?

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

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

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

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

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

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

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

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

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

*до v28

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты ещё скажи что и патент не им принадлежит :)

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