URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 60485
[ Назад ]

Исходное сообщение
"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"

Отправлено opennews , 02-Ноя-09 09:56 
На прошлой неделе компания Apple закрыла (https://www.opennet.ru/opennews/art.shtml?num=23969) открытый проект zfs.macosforge.org (http://zfs.macosforge.org/), занимавшийся адаптацией файловой системы ZFS для платформы MacOS X. Закрытие официального продукта привело к образованию (http://dustin.github.com/2009/10/23/mac-zfs.html) нового свободного проекта MacZFS (http://code.google.com/p/maczfs/), который базируется на ранее созданной Apple кодовой базе, но отличающегося методом интеграции в систему. MacZFS выполняется не на уровне ядра, а на пользовательском уровне, работая с использованием MacFUSE.


Для пользователей MacOS X желающий протестировать новый ZFS-модуль подготовлен (http://code.google.com/p/maczfs/wiki/Building) бинарный пакет, собранный на основе опубликованных в Git-репозитории (http://github.com/dustin/mac-zfs) исходных текстов, а также инструкция (http://code.google.com/p/maczfs/wiki/GettingStarted) по настойке.

URL: http://ostatic.com/blog/apple-scuttles-zfs-community-picks-i...
Новость: https://www.opennet.ru/opennews/art.shtml?num=24074


Содержание

Сообщения в этом обсуждении
"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено klalafuda , 02-Ноя-09 09:56 

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

// wbr


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 02-Ноя-09 12:12 
Вы, вероятно, не знаете что такое ZFS. Это ФС нового поколения, которой нет аналогов. Да, на MacOS X все "настолько" плохо с родными ФС. Собственно, "настолько" плохо везде, где нет ZFS.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено klalafuda , 02-Ноя-09 12:25 

черт возьми, нельзя так пугать людей! у меня уже сердце не на месте, что вот-вот все мои ext3 посыплются как одна бо устарели'с и им давно пора в утиль. а я то и не знал :-/

// wbr


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 12:48 
Не волнуйтесь так и не комплексуйте. Юзайте себе хоть FAT12.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Дмитрий Ю. Карпов , 02-Ноя-09 14:32 
Файловые системы должны развиваться. IMHO, уже пора делать новые файловые системы - теория накопила достаточно материала, чтобы воплощать его в практику.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 16:34 
> что вот-вот все мои ext3 посыплются как одна бо устарели'с

Посыпаться то они не посыпятся, но вот если увидеть скажем, скорость работы хотя-бы ext4 на той же самой конфиге... :-)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено СуперАноним , 02-Ноя-09 16:02 
Ну там, где есть BtrFS, уже настолько хорошо, что ZFS совсем не нужна.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 16:14 
а brtfs - она уже production-ready?

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 16:37 
>а brtfs - она уже production-ready?

А ZFS пока-что "production ready" только у санок как я понимаю. Еще относительно скоро наверное будет у бсдшников. Макинтошники ... ну блин на то оно и проприетарь что юзерам этого только и остается сроду что слать смс на короткий номер с текстом "не лох". Это крутая фича, лет через 15 может проприетарщикам и надоест пичкать всех антикварным хламом и они даже продадут это как крутую фичу :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено user234 , 02-Ноя-09 17:30 
btrfs нет смысла сравнивать с zfs. zfs вообще с большой натяжкой можно назвать файловой системой, это менеджер томов. да и по устройству btrfs это скорее реинкарнация reiserfs

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 17:55 
>btrfs нет смысла сравнивать с zfs.

Почему? Они достаточно похожи по набору фич, у бтр тоже манагер томов есть.

>zfs вообще с большой натяжкой можно назвать файловой системой,

Блин, а чем ее тогда называть? Холодильником чтоли? Как по мне так это версионная ФС :)

>это менеджер томов.

Нет, это не менеджер томов, это версионная ФС. Да, с встроенным манагером томов. Самое интересное что про БТР можно сказать то же самое. Дело в том что когда манагер томов внесен на слой ФС - у него появляются некоторые интересные возможности, если заранее предусмотрено дизайном ФС. В БТР на этот счет при разработке постарались.

>да и по устройству btrfs это скорее реинкарнация reiserfs

Btrfs - не есть реинкарнация reiserfs ни в каком виде. По устройству оно версионник. Рейзер никогда версионником не был. А так да, "кукурузник" и "боинг" оба самолеты и у обоих есть крылья, фюзеляж и шасси. Стало быть, боинг - реинкарнация кукурузника? :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 02-Ноя-09 18:41 
> Как по мне так это версионная ФС :)

версионные ФС (Hammer, Tux3, NILFS) по дефолту хранят историю. ZFS - нет. У них используется CoW и ZIL, что не является заменой версионности.

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


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 20:15 
>У них используется CoW и ZIL, что не является заменой версионности.

Дело тут вот в чем: в моем понимании, логика в стиле CoW - основа версионников. Хотя да, вы правы в том что я в строгом понимании скорее говорил про "CoW-подобные" ФС нежели про "версионники". Называют оное действо по разному, но суть как я понимаю примерно одна: измененные блоки дописываются в сторонку а метаданные описывающие размещение блоков обновляются для учета того что вон те блоки - брать теперь вот там. Столь нехитрая но изобретательная логика и позволяет устраивать крутизну типа кучи снапшотов и прочая, на ходу и быстро, ради чего обычно и затевается. Т.к. снапшотирование на такую схему ложится естественно: все что для этого надо - валидная копия метаданных на некий момент (в момент создания снапшота она уже есть, сугубо для нормальной работы ФС) + чтобы блоки были на месте.

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

А (не)автоматичность этой операции и ее окончательная цена и гранулярность - на совести дезигнеров конкретной ФС :). Поэтому я и обзываю подобные дизайны "версионниками". Потому что с таким дизайном возможно продвинутое управление версиями и оно просто и быстро. Если предложите более вменяемое название - я подумаю о его использовании.

>Ты не можешь восстановить случайно удаленный файл, если не сделал предварительно снапшота.

Но в конечном итоге, возможность быстрого снапшотирования и отката на снапшот - и есть базовое свойство CoW-подобных дизайнов и версионности. Пачка снапшотов - несколько версий ФС в разные моменты времени. За что я и называю это версионником, хоть я и понимаю что вы имели в виду.

Безусловно - можно реализовать эту схему своеобразно. Вот сани что-то такое и сделали, как-то странновато и далеко не лучшим образом. Я не понимаю чего от нее так кипятком ссут. Наверное потому что у них другого нет и потому что оно было одним из первых и навороченное :D.

ИМХО, бтр сделан куда интереснее. Оно как я понял периодически лепит контрольные точки автоматически, в принципе позволяя как раз то о чем вы написали. И снапшоты как я понимаю там сводятся к чуть ли не установке флажка запрещающего GC подчищать данные и метаданные некоего чекпойнта. Что ессно почти мгновенная операция а все что было надо для снапшота и так было на его момент, просто пометили это как неубиваемое и вот вам постоянный снапшот, дескать :). При том - CPU в таких схемах жрать особо нечему, снапшоты получаются весьма дешевой операцией.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено iZEN , 02-Ноя-09 18:13 
>>а brtfs - она уже production-ready?
>
>А ZFS пока-что "production ready" только у санок как я понимаю.

На FreBSD давно уже ZFSv13 "production ready".


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено bill , 02-Ноя-09 19:15 
Правильно, что взял в кавычки. А то можно было случайно всерьёз воспринять.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено iZEN , 02-Ноя-09 19:56 
>Правильно, что взял в кавычки. А то можно было случайно всерьёз воспринять.

Случайно всерьёз воспринять не получится — у меня машинка уже на ZFSv13-only с августа месяца. Ничего не поделаешь — приходится воспринимать всерьёз, а иначе работать на сферическом коне из вакуума просто так невозможно — голова и хвост всё время проглядывают сквозь толстый хрустальный шар.



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено bill , 02-Ноя-09 21:53 
>>Правильно, что взял в кавычки. А то можно было случайно всерьёз воспринять.
>
>Случайно всерьёз воспринять не получится — у меня машинка уже на ZFSv13-only
>с августа месяца. Ничего не поделаешь — приходится воспринимать всерьёз, а
>иначе работать на сферическом коне из вакуума просто так невозможно —
>голова и хвост всё время проглядывают сквозь толстый хрустальный шар.

Твоя машинка это всего лишь твой localhost. Сильный аргумент для обоснования "production ready" :D


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 22:09 
у меня ZFSv13 уже в продакшене, за последние пару недель на 5-ть новых серверов воткнул, правда пока только на бекапных разделах юзаю.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено bill , 03-Ноя-09 09:15 
Отпишись, когда по зад ногой с работы выпрут за потерю бэкапов.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 03-Ноя-09 17:26 
Ну не дает покоя тебе что ZFS в ляликсе нету, ну не дает.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 20:53 
Ну не дает покоя тебе что ZFS в ляликсе нету, ну не дает.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 20:17 
>На FreBSD давно уже ZFSv13 "production ready".

Я не суеверен, но номер версии мне все-таки нравится :-). Для полного кайфа рекомендую поиграться в следующую пятницу какими-нить продвинутыми операциями, закатить стресстесты и прочая. Желательно на важных "энтерпрайзных" данных а для остроты ощущений - еще без бэкапа :D


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено iZEN , 02-Ноя-09 20:33 
>>На FreBSD давно уже ZFSv13 "production ready".
>
>Я не суеверен, но номер версии мне все-таки нравится :-). Для полного
>кайфа рекомендую поиграться в следующую пятницу какими-нить продвинутыми операциями, закатить стресстесты
>и прочая. Желательно на важных "энтерпрайзных" данных а для остроты ощущений
>- еще без бэкапа :D

Вы всё ещё думаете, что она валится, а я её использую повседневно уже 3 месяца. С переменной загрузкой CPU (обоих ядер) от 10 до 100% на протяжении десятка часов. Ничего не валится и никуда ничего не пропадает.
ЧЯДНТ?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 22:12 
>уже 3 месяца. С переменной загрузкой CPU (обоих ядер) от 10
>до 100% на протяжении десятка часов.

Я что-то не понял, как загрузка ядер проца влияет на стабильность ФС. Я думал, загрузка ФС сводится к интенсивным файловым операциям.Или ZFS настолько грузит проц? (Ну там есть чему, снапшоты этого ессно не могут делать, но вот расчет чексум, сжатие метаданных а иной раз и данных и прочая - могут)

>Ничего не валится и никуда ничего не пропадает.
>ЧЯДНТ?

"Если вам кажется что дела идут хорошо - значит вы просто чего-то не заметили". Законы Мерфи, однако :-)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено dRiZd , 02-Ноя-09 23:38 
Сдуру на домашнем почтовике решил заменить ext3.
Почтовик отказался работать, но заметил я это к вечеру, когда решил проверить почту - почты нету. Не сохраняется база (в кеше есть, а на диск не сбрасывается) :(

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено dRiZd , 02-Ноя-09 23:45 
На ext2/3/4,reiser3/4,xfs,hfs+ сохраняется, а на btrfs/zfs нет.
Отдельно файлы копируются, логи почтовика сохраняются, а базы нет :(
Странно, однако. Хотя оно и понятно - версионность, но как тогда должен работать софт?

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 03-Ноя-09 17:31 
>На ext2/3/4,reiser3/4,xfs,hfs+ сохраняется, а на btrfs/zfs нет.
>Отдельно файлы копируются, логи почтовика сохраняются, а базы нет :(
>Странно, однако. Хотя оно и понятно - версионность, но как тогда должен
>работать софт?

Сюрприз, из-за версионности ФС начинает как-то по-другому работать с точнки зрения приложений. Просто меньше ври, никто не поверит что ты под своим почтовиком менял 9 файловых систем, а учитывая что btrfs еще нет, zfs если только через fuse, hfs+ r/w только без журнала и т.д...


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Bulgarin , 03-Ноя-09 17:54 
>Сюрприз, из-за версионности ФС начинает как-то по-другому работать с точнки зрения приложений.

сюрприз - приложению вообще по барабану, что там за файловая система.
man 2 open/read/write/close


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено dRiZd , 04-Ноя-09 13:24 
А Вы сначала попробуйте, а потом пишите.
Не все приложения одинаково переносят разные fs.
Кстати postgresql, тоже отказался нормально работать на zfs и btrfs :S

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Aleksey Salow , 04-Ноя-09 15:48 
>А Вы сначала попробуйте, а потом пишите.
>Не все приложения одинаково переносят разные fs.
>Кстати postgresql, тоже отказался нормально работать на zfs и btrfs :S

Блин, а мой постгрес не в курсе что на zfs он работать не должен. Нипарядак.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Bulgarin , 05-Ноя-09 00:06 
>А Вы сначала попробуйте, а потом пишите.
>Не все приложения одинаково переносят разные fs.
>Кстати postgresql, тоже отказался нормально работать на zfs и btrfs :S

С какого панталыка? У меня pgsql для подручных-вспомогательных целей на подручной железяке, так, статистику посчитать скриптами-реляциями, и базы так себе, порядка 0.5-2Gb - даже и не обратил внимание про переносе на zfs, пилит себе и пилит.

При желании, не понимаю, в чем у вас косяк случился.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 20:35 
>Сюрприз, из-за версионности ФС начинает как-то по-другому работать с точнки
>зрения приложений.

С фига ли? Должно работать одинаково. По другому оно работает с точки зрения фичности и скорости в основном. А btrfs - еще явно не для продакшна, так что если кто хочет поиграться с ним карты ему в руки, но если данные опнулись - не говорите что вас не предупреждали. Ну и вообще имеет смысл смотреть его только с распоследними ядрами. Все что до .31 ядра - вообще некромансия, там формат данных на диске несколько поменяли.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено dRiZd , 03-Ноя-09 23:52 
А Вам слабо перекинуть почтовик с Linux на Snow Leopard Server?
Мне нет, поэтому так много fs.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 05-Ноя-09 16:16 
>А Вам слабо перекинуть почтовик с Linux на Snow Leopard Server?

Не очень понял кому это ответ при таком построении дерева треда. Если мне - мне не "слабо" а "на$%# не нужно". А реально - какие от этого плюсы? Я скорее только минусы вижу - зависимость от единственного вендора да еще и не отличающегся скромностью.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 20:31 
>Сдуру на домашнем почтовике решил заменить ext3.

На что? На btrfs? Мсье камикадзе? :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено dRiZd , 03-Ноя-09 23:56 
Вот я и написал - сдуру. Тем более v0.16

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 04-Ноя-09 01:21 
>Тем более v0.16

Реально сдуру. Там с 0.19 то народ находит грабельки весьма хорошего калибра, гхм. Вы до того как экспериментальное что-то ставить - ченжлоги хотя-бы читайте для понимания того что там СЕЙЧАС происходит. А если у вас еще и версия "год назад" так за год у опенсорсников порой меняется целая эпоха как я погляжу. Вон какойнить кутим год назад был куда как горбатее чем сейчас например, хотя и сейчас своеобразен.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 21:00 
RC1 работает два месяца в продакшн, все замечательно. iozone и bonnie++ гоняли в процессе тестирования несколько суток - никаких проблем (а именно на них ZFS падал когда-то).

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 02-Ноя-09 17:20 
> Ну там, где есть BtrFS, уже настолько хорошо, что ZFS совсем не нужна.

Т.е. нигде?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 16:39 
>что хоть кровь из носу но позарез нужна ZFS?

Как сказать. Вам не приходило в бошку что версионники обладают рядом свойств которые заметно отличают их от всего остального что было до них?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено MinimumLaw , 02-Ноя-09 10:39 
Да бог его знает. Я на своем хакинтоше особых проблем с HFS+ не заметил, а ZFS - вкусно конечно, но что-то с ней не так. Под win32 её нет, так что кросплатформенная ОС как была VFAT, так и осталась, Linux - так FUSE штука хорошая, но я ей как-то не сильно доверяю. *BSD что-то как-то тоже не шатко не валко. Вот и получается - в соляре вкусно, но только в соляре. Да оно и понятно - там серьезная работа, там надежность - а маку оно зачем? Ну грохнется HFS+ с горой хлама их инета понатянутого, ну переформатировали - переустановили и всё. Свое-то каждый все равно бакапит на что-то более надежное. Сервера в нете, диски оптические... Так что сомнительная вкусность для дома-то. Разве что беспроблемное увеличение дискового объема. Так тоже вопрос. Поколение бьющее диск на тома типа "System", "Software", "Video", "Photo", "Hlam" еще не умерло, и пока не умрет данный плюс ZFS на десктопе весьма сомнителен.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Hedgehog_57 , 02-Ноя-09 11:05 
Честно говоря не понял вашей крайней сентенции.

Я вполне себе из того поколения, которое привыкло бить диск. И тут как раз ZFS очень хорошо вписывается. Потому, что я из единого zpool выделяю несколько zfs, которые шарят одно место на диске. Мне не надо заранее думать, как я буду выкручиваться, когда фотографий окажется больше, чем я предполагал, а вот video или software меньше. Этой проблемы просто нет.

Сейчас мне в LVM не хватает именно этой фишки. Ну, еще онлайнового сжатия и криптования. Но в этом направлении какие-то шаги делаются.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено otaku , 02-Ноя-09 11:27 
А в чем у вас проблема это делать с помощью лвм?
По мойму там все эти фишки есть, только надо файловую систему которая поддерживает уменьшение разделов, увеличение разделов по мойму уже все распространенные файловые системы в линуксе поддерживают.

"> А в чем у вас проблема это делать с помощью лвм?"
Отправлено poige , 02-Ноя-09 11:44 
Это не у него проблема. Если (к примеру) сделать 15 разделов, где будет хотя-бы 10 GiB свободного места, то получается что в сумме 150 GiB свободны. Если затем у одного из разделов останется только 5 GiB свободных, то куча общего свободного места никак не поможет -- файловые системы разные, и на суммарные свободные 140 GiB остальных разделов можно только облизываться.

"> А в чем у вас проблема это делать с помощью лвм?"
Отправлено Frank , 02-Ноя-09 12:18 
именно поэтому надо грамотно подходить к разбивке места, а не резать на дцать разделов, когда в них нет никакой необходимости
не умеешь правильно разделять место на разделы - держи всё в одном разделе и не морочь себе яйца

"> поэтому надо грамотно подходить"
Отправлено poige , 02-Ноя-09 12:47 
Чуваки из Sun решили, что они не настолько грамотные, как Фрэнк с оупиннэт и заморочили себе яйца созданием ZFS. Болваны, безусловно...

"> поэтому надо грамотно подходить"
Отправлено fi , 02-Ноя-09 12:56 
Чуваки из Sun всю свою жизнь херней страдали, даже при ufs (еще даже в соляре2) пилили диск на кучу меких кусочков с запасом 5% - поубивал бы!!! Приходилось вновь пришедшие системы заного инсталировать. Иной раз доходило, что апдейты не ставились!!!



"> поэтому надо грамотно подходить"
Отправлено User294 , 02-Ноя-09 18:01 
И ZFS странноват дизайном, но "по мотивам" был сделат btrfs, в котором много чего сделано получше... :)))

"> поэтому надо грамотно подходить"
Отправлено iZEN , 02-Ноя-09 18:16 
>И ZFS странноват дизайном, но "по мотивам" был сделат btrfs, в котором
>много чего сделано получше... :)))

Очень много слышал (от тебя, в основном), что Btrfs сделана лучше ZFS, но конкретных деталей "чем лучше" ("чем грузины"?) не уловил.
Разъясни, а?


"> поэтому надо грамотно подходить"
Отправлено vitek , 02-Ноя-09 18:27 
http://moradan.sopovs.com/2009/07/evangelist-failovix-sistem...
>При этом более интересны различия в архитектуре.
>На самом высоком уровне ZFS использует концепцию плоских деревьев из указателей на блоки, стиль FFS и переменный размер блока, навеянный планировщиком памяти ядра SLAB. Btrfs использует использует дружественные к COW (копирование при записи) B-деревья (в том виде, в каком это представлено Охадом Родехом (Ohad Rodeh) на LSF ‘07) и экстенты. На самом деле btrfs ещё немного лучше, чем можно подумать: каждый кусок данных или метаданных в btrfs - это объект в B-дереве, и эти объекты группируются вместе вперемешку - без оглядки на их тип. ZFS сужает абстракцию всех метаданных и данных до объектов и относящихся к ним операций; btrfs сузила эту абстракцию до листьев B-дерева. После этого самым интересным стало решение проблемы присвоения ключей объектам этого дерева и их упорядочения.
>Ну и сейчас я могу сказать своё личное/фанатичное мнение. С самого начала, я думала, что подход ZFS был проще и чище - в то время код для управления B-деревьями и экстентами был очень усложнён и добавление к нему копирования при записи и контрольных сумм скорее всего привело бы к взрыву мозга. Но после того, как Охад Родех упростил реализацию и сделал её более надёжной, а Крис Масон (Chris Mason) представил свою концепцию "всё есть лист дерева", моё мнение изменилось. Я неофит этого подхода.

"> поэтому надо грамотно подходить"
Отправлено iZEN , 02-Ноя-09 19:58 
>>Ну и сейчас я могу сказать своё личное/фанатичное мнение. С самого начала, я думала, что подход ZFS был проще и чище - в то время код для управления B-деревьями и экстентами был очень усложнён и добавление к нему копирования при записи и контрольных сумм скорее всего привело бы к взрыву мозга. Но после того, как Охад Родех упростил реализацию и сделал её более надёжной, а Крис Масон (Chris Mason) представил свою концепцию "всё есть лист дерева", моё мнение изменилось. Я неофит этого подхода.

Ж)

Итак, ждём тестов Btrfs vs. ZFS.


"> поэтому надо грамотно подходить"
Отправлено vitek , 02-Ноя-09 20:11 
для начала ждём саму btrfs! :-D

"> поэтому надо грамотно подходить"
Отправлено moradan , 09-Ноя-09 22:28 
О Боже, у меня до сих пор там Мейсон обозван Масоном? Какой ужас...

"> поэтому надо грамотно подходить"
Отправлено User294 , 03-Ноя-09 00:10 
>Разъясни, а?

Разъясняю - я почитал описалово их устройств, ну и некоторые коменты на этот счет. И сравнил. Чего и вам рекомендую.


"> А в чем у вас проблема это делать с помощью лвм?"
Отправлено Wulf , 02-Ноя-09 12:55 
> держи всё в одном разделе и не морочь себе яйца

Кстати, именно такой подход и заложен в идеологии ZFS. Солярка, например, при установке на ZFS вообще все пишет в один раздел, точнее zpool. А в этом zpool-е только 2-а zfs-a: / и /export/home. Еще можно, при желании, /var сделать. И все. Никаких /usr /opt и т.п. как в случае с ffs-ом. И никаких проблем с "грамотным подходом к разбивке места"


"> А в чем у вас проблема это делать с помощью лвм?"
Отправлено vitek , 02-Ноя-09 12:28 
чтобы не писать чушь - http://www.xgu.ru/wiki/LVM - а именно следующее:
# 1.4 Создание группы томов
# 1.5 Активация группы томов
# 1.6 Удаление группы томов
# 1.7 Добавление физических томов в группу томов
# 1.8 Удаление физических томов из группы томов
# 1.9 Создание логического тома
# 1.10 Удаление логических томов
# 1.11 Увеличение логических томов
# 1.12 Уменьшение размера логического тома
# 1.13 Перенос данных с физического тома
а также:
# 4.2 Создание зашифрованных томов LVM
# 4.5 Слияние LVM

"> А в чем у вас проблема это делать с помощью лвм?"
Отправлено klalafuda , 02-Ноя-09 12:47 

к сожалению, текст по ссылки читать практически невозможно в силу специфического русского языка (IMHO), так что не поленюсь привести оригинальную ссылку:

http://tldp.org/HOWTO/LVM-HOWTO/benefitsoflvmsmall.html

--- cut ---
2.2. Benefits of Logical Volume Management on a Small System

One of the difficult decisions facing a new user installing Linux for the first time is how to partition the disk drive. The need to estimate just how much space is likely to be needed for system files and user files makes the installation more complex than is necessary and some users simply opt to put all their data into one large partition in an attempt to avoid the issue.

Once the user has guessed how much space is needed for /home /usr / (or has let the installation program do it) then is quite common for one of these partitions to fill up even if there is plenty of disk space in one of the other partitions.

With logical volume management, the whole disk would be allocated to a single volume group and logical volumes created to hold the / /usr and /home file systems. If, for example the /home logical volume later filled up but there was still space available on /usr then it would be possible to shrink /usr by a few megabytes and reallocate that space to /home.

Another alternative would be to allocate minimal amounts of space for each logical volume and leave some of the disk unallocated. Then, when the partitions start to fill up, they can be expanded as necessary.

.........
--- cut ---

и тд и тп.

// wbr


"> А в чем у вас проблема это делать с помощью лвм?"
Отправлено vitek , 02-Ноя-09 13:10 
и что?
я не понял в поддержку кого (или чего) Вы это привели?

если буржуйский Вам более понятен (а судя по апломбу это так), то первые 2-а предложения - это ситуация без lvm, а остльные - с lvm. начиная отсюда:
>With logical volume management, the whole disk would be allocated to a single volume group and logical volumes created to hold the / /usr and /home file systems. If, for example the /home logical volume later filled up but there was still space available on /usr then it would be possible to shrink /usr by a few megabytes and reallocate that space to /home.

с переводом надеюсь проблем не будет?

зы:
язык вполне понятен, не нужно напраслину наводить.
и вообще, xgu - отличный проэкт .


"> shrink /usr by a few megabytes and reallocate that space to"
Отправлено poige , 02-Ноя-09 13:35 
sudo resize2fs /dev/vg3/test 8G
resize2fs 1.41.8 (11-July-2009)
Filesystem at /dev/vg3/test is mounted on /m/test; on-line resizing required
On-line shrinking from 3932160 to 2097152 not supported.

-- удаче... On-line shrinking насколько я знаю, не поддерживает ни одна из стабильных линуксовых FS. Мало читать wiki "отличного проекта xgu", чтобы не оказаться теоретизирующим умником.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 13:48 
а почему тогда выдержка не с "отличного проекта xgu"? :-D

и кстати уже делал. и не раз.
более того!!!  ext2resize входит в такую утиль, как GNU parted (и его фронтэнд - QtParted) http://ext2resize.sourceforge.net/
как! Вы будите утверждать, что и parted не работает?!!! :-DDDDDDDDDDDDDDDDDDDDDDDDD
а ведь именно ей все диски и бью.... даже ntfs отлично резайзит.

зы:
а вот и faq - http://ext2resize.sourceforge.net/faq.html
и обратите внимание ещё на xfs.


"> и обратите внимание ещё на xfs."
Отправлено poige , 02-Ноя-09 14:22 
XFS на 2009-й год вообще не поддерживает shrink, не только on-line, но даже off-line: http://xfs.org/index.php/XFS_FAQ#Q:_Is_there_a_way_to_make_a...

Учи матчасть, Шура.


"> и обратите внимание ещё на xfs."
Отправлено vitek , 02-Ноя-09 14:32 
т.е. из всего вышесказанного Вы прицепились только к xfs.
следует ли это понимать, что в остальном Вы ложанулись? (про мат.часть кстати):-DDDDDDDDD
зы:
xfs привёл к тому, что это отличная fs сама по себе. увеличить её размер можно в смонтированном состоянии. $ man xfs_growfs
xfs_growfs, xfs_info - expand an XFS filesystem
SYNOPSIS       xfs_growfs [ -dilnrxV ] [ -D size ] [ -e rtextsize ] [ -L size ] [ -m maxpct ] [ -t mtab ] [ -R size ] mount-point
       xfs_info [ -t mtab ] mount-point
DESCRIPTION    xfs_growfs expands an existing XFS filesystem (see xfs(5)). The mount-point argument is the pathname of the directory where the filesystem is mounted. The filesystem must be mounted to be grown (see mount(8)). The existing contents of the filesystem are undisturbed, and the added space becomes available for additional file storage.

"> и обратите внимание ещё на xfs."
Отправлено аноним , 02-Ноя-09 14:37 
Разве речь не о shrink шла?

"> и обратите внимание ещё на xfs."
Отправлено vitek , 02-Ноя-09 14:53 
речь шла об lvm.

под lvm могут быть разные фс. и с увеличением, и с уменьшением размера. у каждой свои достоиства и недостатки.

про невозможность ресайзить ext'ы poige слил....

ухватился за последнюю строку об xfs (из раздела ЗЫ: :-DDDDDDDDDDDDDDDDDDDDD).

я ответил на Ваш вопрос?


"> и обратите внимание ещё на xfs."
Отправлено Антон , 02-Ноя-09 15:00 
>речь шла об lvm.
>
>под lvm могут быть разные фс. и с увеличением, и с уменьшением
>размера. у каждой свои достоиства и недостатки.

Вам же на пальцах уже разжевали про что речь. Есть два раздела по 10 Гб - A  и B, а каждом свободно 5 Гб. В ZFS в любой раздел можно сразу записать 10 Гб, а в LVM вам нужно руками один раздел уменьшить, а другой увеличить.


"> LVM вам нужно руками один раздел уменьшить"
Отправлено poige , 02-Ноя-09 15:06 
+ учитывая, что нет ни одной стабильной FS'ки, которая поддерживает on-line shrink, это нужно делать с отмонтированием…

Вобщем, из аргументов против ZFS один придурок говорит, что надо быть бабкой Вангой и знать всё заранее, другой тычет в wiki по LVM.


"> LVM вам нужно руками один раздел уменьшить"
Отправлено syeg , 02-Ноя-09 15:12 
>+ учитывая, что нет ни одной стабильной FS'ки, которая поддерживает on-line shrink,
>это нужно делать с отмонтированием…
>
>Вобщем, из аргументов против ZFS один придурок говорит, что надо быть бабкой
>Вангой и знать всё заранее, другой тычет в wiki по LVM.
>

reiserfs я от безделья ресайзил во все концы еще в SuSE 9.2


"> reiserfs я от безделья ресайзил во все концы еще в SuSE 9.2"
Отправлено poige , 02-Ноя-09 15:33 
-- Появился 3-й, который не понимает разницу между on-line resize и off-line.

reiserfs's dmesg: "Can't shrink filesystem on-line."


"> reiserfs я от безделья ресайзил во все концы еще в SuSE 9...."
Отправлено syeg , 02-Ноя-09 15:37 
>-- Появился 3-й, который не понимает разницу между on-line resize и
>off-line.
>
>reiserfs's dmesg: "Can't shrink filesystem on-line."

Да, я не знал что ресайз примонтированного раздела называется off-line.


"> ресайз примонтированного раздела называется off-line."
Отправлено poige , 02-Ноя-09 15:42 
/usr/src/2.6.31/linux-2.6.31/fs/reiserfs/resize.c:

int reiserfs_resize(struct super_block *s, unsigned long block_count_new)
{
[...]
        if (SB_BLOCK_COUNT(s) >= block_count_new) {
                printk("can\'t shrink filesystem on-line\n");
                return -EINVAL;
        }


"> ресайз примонтированного раздела называется off-line."
Отправлено syeg , 02-Ноя-09 15:48 
Хм, действительно, туплю. Growth only. Что же я тогда ресайзил... Несколько лет прошло, не вспомню уже. Хотя точно помню, что какой-то раздел уменьшал и увеличивал другой.

"> LVM вам нужно руками один раздел уменьшить"
Отправлено User294 , 03-Ноя-09 20:41 
>reiserfs я от безделья ресайзил во все концы еще в SuSE 9.2

А у "ословодов" (ака авторов aMule) на серванте рейзер3 не так давно характерно сдох, собрать том потом вообще не смогли, fsck облажался. Коменты оных по поводу даунтайма и рейзера - понятны. Толку то с ресайзов, если у него fsck стремный? При том понимаю б ословоды были единственные кто на такое ругается, но ведь гугля видит и еще легион счастливчиков.


"> и обратите внимание ещё на xfs."
Отправлено syeg , 02-Ноя-09 15:11 
Чего-то я не понял. ZFS она что, сама решает куда данные лить? Т.е. все имеющиеся пулы представляет одной цельной ФС? Т.е. в случае переполнения раздела с логами получаем переполнение корневого раздела и опаньки?
/me не выдержал, и пошёл ставить солярку для проверки.

"> и обратите внимание ещё на xfs."
Отправлено Anon Y Mous , 02-Ноя-09 15:24 
Квоты и резервации никто не отменял

"> и обратите внимание ещё на xfs."
Отправлено syeg , 02-Ноя-09 15:35 
>Квоты и резервации никто не отменял

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


"> и обратите внимание ещё на xfs."
Отправлено Денис Юсупов , 02-Ноя-09 16:13 
А вы даёте идиотам возможность отключения квот и резерваций? Кошерненько %)

"> и обратите внимание ещё на xfs."
Отправлено syeg , 02-Ноя-09 16:35 
>А вы даёте идиотам возможность отключения квот и резерваций? Кошерненько %)

Не всегда, но приходится. Т.к. высшее начальство их считает крутыми спецами (уже два года не могут осилить демона написать). Ну и ещё орут они громко - уши дороже.

  


"> и обратите внимание ещё на xfs."
Отправлено аноним , 02-Ноя-09 17:21 
И чем в этом плане они отличаются от битья на резделы?

"> и обратите внимание ещё на xfs."
Отправлено Anon Y Mous , 02-Ноя-09 21:09 
> И чем в этом плане они отличаются от битья на резделы?

А подумать? Тем, что пространство свободное при этом объединено в пуле, а не попилено на части в разные разделы. И чтобы квоту или резервацию подвинуть - никаких особенных телодвижений с перемещением границ разделов, увеличением/уменьшением логических томов и прочего не нужно. Просто

zfs set quota=1G tank/anonim


"> и обратите внимание ещё на xfs."
Отправлено аноним , 03-Ноя-09 00:26 
Я про это вообще-то и говорю. А товарищ вон считает что ZFS'ные квоты чем-то хуже yблюдcтва с кучей разделов.

"> и обратите внимание ещё на xfs."
Отправлено iZEN , 02-Ноя-09 20:43 
>Чего-то я не понял. ZFS она что, сама решает куда данные лить?

В общем, да.

>Т.е. все имеющиеся пулы представляет одной цельной ФС?

Наоборот.
Все имеющиеся ФС (ZFS'ы, ZVOL'ы с UFS) представляются одним пулом (zpool).

>Т.е. в случае
>переполнения раздела с логами получаем переполнение корневого раздела и опаньки?

Именно так. (Хотя выснить, что там представляет из себя "корневой раздел" в данном контексте не представляется возможным, — это ж zpool, в общем случае, с ZFS в корне).


"> и обратите внимание ещё на xfs."
Отправлено vitek , 02-Ноя-09 16:06 
>Вам же на пальцах уже разжевали про что речь. Есть два раздела по 10 Гб - A  и B, а каждом свободно 5 Гб. В ZFS в любой раздел можно сразу записать 10 Гб, а в LVM вам нужно руками один раздел уменьшить, а другой увеличить.

ровно в 2-а раза больше операций....
зато я знаю что делаю и точно знаю, что мои порнофильмы не валяются в том же цилиндре, что ядро.

(про online resizing см. ниже/выше - надоело писать ;-))


"> и обратите внимание ещё на xfs."
Отправлено Bulgarin , 03-Ноя-09 01:06 
>зато я знаю что делаю и точно знаю, что мои порнофильмы не валяются в том же цилиндре, что ядро.

Да шо ты балакаешь? Ну как будто только от ручного форматирования диска Единой Серии.
Многие годы как контролер диска токой вумный, что сам решает, на какой трэк ему что писать, выдавая тебе фейковую инфу, шоб ты ему верил как родному.
Так что не беспокойся - ядро давно плавно размазано по блину промеж прочей порнографии :)


"> и обратите внимание ещё на xfs."
Отправлено Да пофиг на имя , 02-Ноя-09 16:38 
>Вам же на пальцах уже разжевали про что речь. Есть два раздела
>по 10 Гб - A  и B, а каждом свободно
>5 Гб. В ZFS в любой раздел можно сразу записать 10
>Гб, а в LVM вам нужно руками один раздел уменьшить, а
>другой увеличить.

Создаешь вместо логического тома снапшот с размером, раным размеру всей группы томов. И так хоть 100 раз. Получишь в точности то, что описал.


"> и обратите внимание ещё на xfs."
Отправлено poige , 02-Ноя-09 15:02 
> про невозможность ресайзить ext'ы poige слил....

Да ну, правда что-ли? «… GNU ext2resize is a package which allows resizing ext2 and ext3 filesystems (both shrinking and growing). The ext2resize tool is for resizing unmounted filesystems, and ext2online is for growing a mounted filesystem (it needs a kernel patch to work, however). …»

Так что ПНХ.


"> и обратите внимание ещё на xfs."
Отправлено vitek , 02-Ноя-09 15:54 
статья 2002 года. а вот что есть в бубунте:
$ man resize2fs
resize2fs - ext2/ext3/ext4 file system resizer
SYNOPSIS
       resize2fs [ -fFpPM ] [ -d debug-flags ] [ -S RAID-stride ] device [ size ]
DESCRIPTION
       The  resize2fs program will resize ext2, ext3, or ext4 file systems. It can be used to enlarge or shrink an unmounted file system located on device. If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel supports on-line resizing. (As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 only.).

зы:
для одарённых - (As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 only.).


"> для одарённых"
Отправлено poige , 02-Ноя-09 16:26 
Одарённый как раз ты, и даже не удивлюсь, если у тебя со слоном всё пройдёт успешно. А если по теме, то расскажи-ка, чудило, как ты собрался те 14 EXT3-разделов (на LVM), общим объёмом 140 GiB, уменьшать (on-line), чтобы наскрести недостающего места. С учётом того, что нет ни одной стабильной FS в Linux, которая поддерживает shrink, разумеется. ;-)

"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено JL2001 , 02-Ноя-09 14:22 
>а вот и faq - http://ext2resize.sourceforge.net/faq.html
>и обратите внимание ещё на xfs.

#
Can I resize a filesystem while it is mounted?

Yes you can, using the ext2online program (part of the ext2resize package). However, you need to have a kernel patch in order to do this. Please read the documentation in the package.
#
Can I resize an ext3 filesystem (while it is mounted)?

Yes you can, but only using the CVS version of ext2resize or ext2online. You still need to have a kernel patch in order to do this. Please read the documentation in the package.

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

а вобще в идеале файловая система могла бы и сама распределять свободное место по требованию (как это и делает zfs, чем меня очень привлекает)


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 14:49 
с устаревшими хавту первый раз встречаетесь?
оттуда - http://ext2resize.sourceforge.net/online.html (2002 год!!!)
>here are patches available for 2.0, 2.2, 2.4, and 2.6. The actual functionality of the patch hasn't changed much since its inception.

иначе говоря - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321556 (2005 год!!!)
>Online resizing of ext2 and ext3 filesystems appears to be supported in

the linux 2.6.12 kernel.
и т.д. (а лучшая и актуальная дока - исходники)
зы:
и всем остальным - тут, вниузу, уже про кластерное расширение к lvm2 упоминали - http://sources.redhat.com/cluster/clvm/
а как там с этим у zfs? (а то видишь ли shrink нет... зато кластер есть!!! :-D)


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено JL2001 , 02-Ноя-09 15:09 
>иначе говоря - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321556 (2005 год!!!)
>>Online resizing of ext2 and ext3 filesystems appears to be supported in

"Only growing is supporting, not shrinking."
а вобще я не специалист, мб с 2005го уже и shrinking supporting


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Anon Y Mous , 02-Ноя-09 15:36 
>и всем остальным - тут, вниузу, уже про кластерное расширение к lvm2
>упоминали - http://sources.redhat.com/cluster/clvm/
>а как там с этим у zfs? (а то видишь ли shrink
>нет... зато кластер есть!!! :-D)

ZFS вполне себе работает под управлением Open HA Cluster. А если вы про параллельный доступ с нескольких хостов, то кластерные заморочки LVM ничем в этом смысле не помогут какой-нибудь Ext3/4.

Вы вот лучше скажите, чем Линукс в плане дедупликации может похвастаться?



"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 16:29 
>ZFS вполне себе работает под управлением Open HA Cluster.

оракловый rac пойдёт? :-DDDDDDDDDDDDDDDDDDD
>LVM ничем в этом смысле не помогут какой-нибудь Ext3/4.

может быть... но ...  http://sources.redhat.com/cluster/clvm/
>The LVM2 locking library and clvmd userland daemon depend on the CMAN cluster manager and DLM lock manager.

....
>Вы вот лучше скажите, чем Линукс в плане дедупликации может похвастаться?

про какую дедупликацию речь?


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Anon Y Mous , 02-Ноя-09 17:25 
>>Вы вот лучше скажите, чем Линукс в плане дедупликации может похвастаться?
>про какую дедупликацию речь?

данных на диске


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 17:34 
чтобы говорить о ДЕдупликации (в любой Ос.... в линухе к примеру, раз Вы затронули),
то вначале скажите где там и в каком месте идёт ДУпликация, чтобы её ДЕДУплицировать приходилось.

надеюсь понятно изложил.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Anon Y Mous , 02-Ноя-09 19:18 
>чтобы говорить о ДЕдупликации (в любой Ос.... в линухе к примеру, раз
>Вы затронули),
>то вначале скажите где там и в каком месте идёт ДУпликация, чтобы
>её ДЕДУплицировать приходилось.
>
>надеюсь понятно изложил.

Понятно, дедупликацию данных на диске линукс не умеет ;-)


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 19:51 
ну Вы уж поясните, раз такой опытный и умный. а то - не солидно. :-D
поясните народу, что это за новомодное энтерпрайзное словечко - дедупликация!!!
а то всё старьём всяким (типа рсинк и подобные) пользуемся... правда и горя не знаем. ;-)

"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено mnu , 02-Ноя-09 20:31 
http://en.wikipedia.org/wiki/Venti

вот это (и поверх него http://en.wikipedia.org/wiki/Fossil_(file_system) ) умело дедупликацию ещё очень давно. На основе SHA1, ага. Но от коллизий на практике не страдает.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Anon Y Mous , 02-Ноя-09 21:15 
>http://en.wikipedia.org/wiki/Venti
>
>вот это (и поверх него http://en.wikipedia.org/wiki/Fossil_(file_system) ) умело дедупликацию ещё очень давно.
>На основе SHA1, ага. Но от коллизий на практике не страдает.
>

Это понятно. Но это не в линукс, а в plan9, а в линуксе доступно только через FUSE, то есть это не совсем в линукс, который, как известно, ядро.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Anon Y Mous , 02-Ноя-09 21:13 
>ну Вы уж поясните, раз такой опытный и умный. а то -
>не солидно. :-D
>поясните народу, что это за новомодное энтерпрайзное словечко - дедупликация!!!
>а то всё старьём всяким (типа рсинк и подобные) пользуемся... правда и
>горя не знаем. ;-)

В гугле забанили?


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено iZEN , 02-Ноя-09 19:51 
>чтобы говорить о ДЕдупликации (в любой Ос.... в линухе к примеру, раз
>Вы затронули),
>то вначале скажите где там и в каком месте идёт ДУпликация, чтобы
>её ДЕДУплицировать приходилось.
>
>надеюсь понятно изложил.

"Дупликация" — это случайная или намеренная запись одного и того же файла в разные каталоги файловой системы.
"Дедупликация" — это отслеживание средствами файловой системы дублирующихся файлов и замена их единственной копией без потери семантики работы с ним как с разными файлами. Если файл (уникальный в пределах ФС) меняется в каком-то каталоге, то файловая система создаёт ещё один (теперь уже изменённый) файл. Если реплики файла не меняются, то в ФС хранится только одна копия файла.



"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 19:56 
вот это уже более понятно о какой дедупликации идёт речь.
(а то в ынтырпрайзной среде так "новый" метод инкрементальных бэкапов обзывать стали)

зы:
честно. про это не знаю. мне это не нужно,.. наверное.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено аноним , 02-Ноя-09 21:43 
>(а то в ынтырпрайзной среде так "новый" метод инкрементальных бэкапов обзывать стали)

судя по описанию, это не инкрементальный бэкап. Представьте себе, что у вас файл-сервер с home directory для 1000 пользователей и одной шарой для всех типа tmp. К одному из них попадает файл Pirates_Of_Caribean_Sea_5.mkv размером гектар в 20, он этот файл сначала копирует себе в home, потом копирует в tmp, откуда половина из этой тысячи юзверей копирует этот файл в свои home. В итоге один и тот же файл дублируется фиг знает сколько раз.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено iav , 03-Ноя-09 00:08 
>"Дупликация" — это случайная или намеренная запись одного и того же файла
>в разные каталоги файловой системы.
>"Дедупликация" — это отслеживание средствами файловой системы дублирующихся файлов и замена их
>единственной копией без потери семантики работы с ним как с разными
>файлами. Если файл (уникальный в пределах ФС) меняется в каком-то каталоге,
>то файловая система создаёт ещё один (теперь уже изменённый) файл. Если
>реплики файла не меняются, то в ФС хранится только одна копия
>файла.

Бывает ещё дедупликация на уровне блоков файловой системы (NetAPP, ZFS) и блоков данных (DataDomain, ныне куплена EMC)

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


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Bulgarin , 03-Ноя-09 01:26 
>"Дупликация" — это случайная или намеренная запись одного и того же файла
>в разные каталоги файловой системы.

преднамеренная запись еще одного имени struct inode файла называеся hardlink, и являет собой стандартную функциональность unix file system с бородатых времен.

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

>"Дедупликация" — это отслеживание средствами файловой системы дублирующихся файлов и замена их
>единственной копией без потери семантики работы с ним как с разными

мать мою дивизия...
файл не меняется в каталоге, в каталоге меняется только _ИМЯ_ файла.
какая нахрен деду-пликация? где ее нашли? 8)

не, пойду утоплюсь в стакане с вином... :/



"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено аноним , 03-Ноя-09 12:48 
а если ты расшарил файл по самбе, и юзверь копирует его из одной шары в другую, причем обе шары у тебя на одной и той же файловой системе на сервере, то умный unix тоже сделает hardlink?

"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Bulgarin , 03-Ноя-09 14:17 
>а если ты расшарил файл по самбе, и юзверь копирует его из
>одной шары в другую, причем обе шары у тебя на одной
>и той же файловой системе на сервере, то умный unix тоже
>сделает hardlink?

хех, "расшарил файл по самбе"... терминология, блин...

с какого панталыку? в приложении операции read()/write() над разными file descriptor, которым соответвует разные struct inode в ядре/файловой системе.
в случае с zfs немного посложнеее, и названия другие, но ссуть та же.
или есть новые syscall's? исключительно (linux|bsd|solaris)-only 8)

а ты хочешь сказать, что логика файловой системы должна вылавливать каждое долбаное изменение блоков на диске, вычислять для них хеш (это самый легкий случай, не сравнимать же побайтно), сравнивать его с имеющимися посредством индексной базы, и при успехе поиска не писать блок на диск, а просто делать ссылку на найденыша в мета-данных нового файло?
и в нескольких метаданных файлов будет ссылка на один и тот же блок?
а для каждого блока отдельная подструктура в новом слое-провайдере, в которой счетчик ссылок каждый блок, дабы знать, мона его 512-байтное величество deallocation и затем заюзать, или низя? или каждый раз выстраивать эту структуру из имеющихся данных в матаданных файла?

да ну нафик... :)

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


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено 222 , 03-Ноя-09 15:50 
>[оверквотинг удален]
>изменение блоков на диске, вычислять для них хеш (это самый легкий
>случай, не сравнимать же побайтно), сравнивать его с имеющимися посредством индексной
>базы, и при успехе поиска не писать блок на диск, а
>просто делать ссылку на найденыша в мета-данных нового файло?
>и в нескольких метаданных файлов будет ссылка на один и тот же
>блок?
>а для каждого блока отдельная подструктура в новом слое-провайдере, в которой счетчик
>ссылок каждый блок, дабы знать, мона его 512-байтное величество deallocation и
>затем заюзать, или низя? или каждый раз выстраивать эту структуру из
>имеющихся данных в матаданных файла?

https://www.opennet.ru/openforum/vsluhforumID3/60511.html


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Bulgarin , 03-Ноя-09 16:47 
>>а для каждого блока отдельная подструктура в новом слое-провайдере, в которой счетчик
>>ссылок каждый блок, дабы знать, мона его 512-байтное величество deallocation и
>>затем заюзать, или низя? или каждый раз выстраивать эту структуру из
>>имеющихся данных в матаданных файла?
>
>https://www.opennet.ru/openforum/vsluhforumID3/60511.html

да, читал. что, можно записыватся в восторженные хомячки?  
и что, теперь это отменяет физические ограничения - машически выросла скорость числодробилки, блоки телепатируют сразу в память, минуя шину, ...? :)

можно написать файловую систему, что при записи ищет блок в гугле, и если находит, то записывает урль, но толку от нее? :)

для понимания, "дедубабуплетикация" - это разновидность алгоритма компресии, с данными, размазанными по всему массиву, и с ахрененным индексным словарем либо постоянно на лету, либо постоянно в памяти.

те же яйца вид в профиль zfs set compress=gzip-n zpool, только другой алгоритм в другом месте.

хай живе, конечно, ... можно дедупликацию вынести еще и на scsi контролер... там один хрен между шиной и ферритом десять слоев преобразований, останется только планку в 1gb на плату присобачить :)


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено iav , 04-Ноя-09 01:58 
>а ты хочешь сказать, что логика файловой системы должна вылавливать каждое долбаное
>изменение блоков на диске, вычислять для них хеш (это самый легкий
>случай, не сравнимать же побайтно), сравнивать его с имеющимися посредством индексной
>базы, и при успехе поиска не писать блок на диск, а
>просто делать ссылку на найденыша в мета-данных нового файло?

Вы так это говорите, будто это что-то плохое.
Online-deduplication работает именно так. DataDomain с этой функцией продаётся уже несколько лет, zfs теперь вот будет.


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Bulgarin , 05-Ноя-09 00:14 
>Вы так это говорите, будто это что-то плохое.
>Online-deduplication работает именно так. DataDomain с этой функцией продаётся уже несколько лет,
>zfs теперь вот будет.

Отношусь к данной возможности публично-скептически, в противовес восторженным хомячкам, не вникающим какой ценой подобная функциональность достигается.
Идее более 10 лет, но пока реализации были не то что бы очень.
Верить заявлениям на блоге - ну так на заборе тоже написано, а там дрова.
А так... а я чо.. а ниче... клево :)



"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено Sw00p aka Jerom , 02-Ноя-09 17:08 
>>А если вы про параллельный доступ с нескольких хостов, то кластерные заморочки LVM ничем в этом смысле не помогут какой-нибудь Ext3/4.

а что Ext3/4 кластерные фс ?
и clvm в связке с GFS2 работает (http://www.redhat.com/gfs/)
думаю с OCFS2 от Oracle-а не сравниться
и ваще они расчитаны на всякие там насы саны


"> shrink /usr by a few megabytes and reallocate that space t..."
Отправлено vitek , 02-Ноя-09 17:25 
они - нет.
а clvm - да.
он уровнем ниже, поэтому теоретически сможет разрулить блокировки, синхронный/асинхронный доступ и т.д.

"> ядро патчить надо.."
Отправлено poige , 02-Ноя-09 15:28 
Да не надо ничего патчить, ровно как и слушать идиотов.

Те патчи, на которые это сказачное чудо ссылается ( http://sourceforge.net/tracker/?group_id=3834&atid=303834 ), родом из 2004-о года, для ядра версии 2.6.5. Они давно уже замерджены в mainline и ext3fs давно поддерживает on-line grow.

(Shrink -- нет.)


"> ядро патчить надо.."
Отправлено vitek , 02-Ноя-09 17:29 
т.е. с 2004 в ведре, но что там дальше - Вы не знаете? :-DDDDDDDD
ну хоть по вопросу искать источники стали... а не только бред писать...

демонстрация для одарённых:

# dd if=/dev/zero of=./1.iso count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 51200000 байт (51 MB), 0,634216 c, 80,7 MB/c

# mkdir /1

# mkfs.ext3 ./1.iso
mke2fs 1.41.9 (22-Aug-2009)
./1.iso is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
12544 inodes, 50000 blocks
2500 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=51380224
7 block groups
8192 blocks per group, 8192 fragments per group
1792 inodes per group
Superblock backups stored on blocks:
    8193, 24577, 40961
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

# mount -t ext3 ./1.iso /1 -o loop

# ls -l ./1.iso
-rw-r--r-- 1 root root 51200000 2009-11-02 17:13 ./1.iso

# dd if=/dev/zero of=/1/1.iso count=1000
1000+0 записей считано
1000+0 записей написано
скопировано 512000 байт (512 kB), 0,00642566 c, 79,7 MB/c

# ls -l /1
итого 515
-rw-r--r-- 1 root root 512000 2009-11-02 17:14 1.iso
drwx------ 2 root root  12288 2009-11-02 17:13 lost+found

# resize2fs -f ./1.iso 25M
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on ./1.iso to 25600 (1k) blocks.
The filesystem on ./1.iso is now 25600 blocks long.

# ls -l ./1.iso
-rw-r--r-- 1 root root 26214400 2009-11-02 17:14 ./1.iso

# ls -l /1
итого 515
-rw-r--r-- 1 root root 512000 2009-11-02 17:14 1.iso
drwx------ 2 root root  12288 2009-11-02 17:13 lost+found

# umount /1


"> ядро патчить надо.."
Отправлено poige , 02-Ноя-09 18:18 
e2fsprogs/src/e2fsprogs-1.41.9/resize/online.c

        if (*new_size < sb->s_blocks_count) {
                printf(_("On-line shrinking from %u to %u not supported.\n"),
                       sb->s_blocks_count, *new_size);
                exit(1);
        }

А так да, команду umount немного местами поменять в листинге, и ву-а-ля.


"> ядро патчить надо.."
Отправлено vitek , 02-Ноя-09 18:36 

этот пример я на ходу на убунте проделал.... все желающие могут повторить.

"> все желающие могут повторить."
Отправлено poige , 02-Ноя-09 20:14 
Извини, признаю, я был неправ, когда уличал тебя в подлоге насчёт umount. :-) Но так мне тебя ещё больше жаль. Знаешь, что тебе выдаст e2fsck 1.iso после тех манипуляций? -- Да ничего хорошего, поверь (проверь). А знаешь, почему ты облажался? Вот на той же Ubuntu:

# mkdir test.dir && cd test.dir && mkdir mntdir
# dd if=/dev/zero of=512M bs=256M count=2
# mkfs.ext3 -F 512M && mount -oloop 512M mntdir && mount|grep mntdir

(* в этом месте получаем вывода типа: *)
/dev/loop0 on /root/test.dir/mntdir type ext3 (rw)

(* пробуем resize по имени ус-ва: *)
# resize2fs /dev/loop0 511M
resize2fs 1.41.9 (22-Aug-2009)
Filesystem at /dev/loop0 is mounted on /root/test.dir/mntdir; on-line resizing required
On-line shrinking from 131072 to 130816 not supported.

(* А теперь -- дискотека: *)
# resize2fs 512M 511M
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on 512M to 130816 (4k) blocks.
The filesystem on 512M is now 130816 blocks long.

Как уже говорил, после такого издевательства над файлом-образом, fsck -- твой друг навек.

"по состоянию на 2009 год возможность on-line resize у стабильных линуксовых FS'ок отсутствует напрочь" (c)


"> on-line resize"
Отправлено poige , 03-Ноя-09 12:15 
О-писка, должно быть "on-line shrink".

"> ядро патчить надо.."
Отправлено Аноним , 02-Ноя-09 20:38 
>e2fsprogs/src/e2fsprogs-1.41.9/resize/online.c

Ради интереса посмотрел исходники последней версии пакета e2fsprogs из Ubuntu. Подтверждаю, вместо кода уменьшения размера для смонтированных ФС стоит заглушка с выводом предупреждения, что такая операция не поддерживается.

2 vitek: трудно было проверить самому, прежде чем раводить флейм ?


"> ядро патчить надо.."
Отправлено Аноним , 02-Ноя-09 22:44 
А теперь немного приблизьте эксперимент к реальным условиям:
1. скопируйте на ваш разлел 50 Мб небольших файлов, допустим из /usr/bin.
2. Удалите половину, скопируйте еще 25 Мб, удалите опять половину случайным образом.
3. Посчитайте для оставшихся 25 Мб  MD5 хэши.
4. Выполните resize2fs в сторону уменьшения.
5. Отмонтируйте раздел, опять примонтируйте.
6. Посчитайте еще раз MD5 хэши.
7. Удивитесь, что оказывается не все хэши совпали :-)

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Frank , 02-Ноя-09 12:16 
> я из единого zpool выделяю несколько zfs, которые шарят одно место на диске

а я из единого /dev/sda1 выделяю несколько директорий, которые шарят одно место на диске.
Так зачем извращаться?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено JL2001 , 02-Ноя-09 14:25 
>> я из единого zpool выделяю несколько zfs, которые шарят одно место на диске
>
>а я из единого /dev/sda1 выделяю несколько директорий, которые шарят одно место
>на диске.
>Так зачем извращаться?

можно поподробнее как делается "шара директориями одного места на диске" ?


"> можно поподробнее как делается 'шара"
Отправлено poige , 02-Ноя-09 15:37 
"Одно место" :-) можно шарить через mount --bind. Только так ZFS всё равно не получишь. :-))

"> можно поподробнее как делается 'шара"
Отправлено JL2001 , 02-Ноя-09 16:34 
маленький офтопик:
а как кроме бинда можно бы один диск подсоединить в два места чтоб например bin и home на одном диске а рут на другом ?
и можно ли через фстаб прописывать бинды ?

"> можно поподробнее как делается 'шара"
Отправлено vitek , 02-Ноя-09 18:03 
а симлинки запретили?

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено iav , 03-Ноя-09 00:20 
>> я из единого zpool выделяю несколько zfs, которые шарят одно место на диске
>
>а я из единого /dev/sda1 выделяю несколько директорий, которые шарят одно место
>на диске.
>Так зачем извращаться?

Чтобы установить для этой директории ограничение занимаемого объёма сверху?
чтобы установить для этой директории резервацию объёма (то есть никакая другая ФС его не сможет занять)?
Чтобы сделать снапшот этой директории?
Чтобы отправить инкрементальный снапшот этой директории в другой пул, который может быть на другой машине?
Чтобы установить другие свойства для этой директории? Такие, как включить/выключить компрессию, поменять размер блока, включить шифрование, установить другое количество копий информации, "только для чтения", и прочее подобное?
Чтобы иметь возможность её отмонтировать, потому что вам это удобно перед запуском какой-то глобальой опрации?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Sw00p aka Jerom , 02-Ноя-09 12:35 
http://sources.redhat.com/cluster/clvm/

Clustering extensions to the standard LVM2 toolset allow existing LVM2 commands to simply and safely manage shared storage. The LVM2 locking library and clvmd userland daemon depend on the CMAN cluster manager and DLM lock manager.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 12:56 
>Да бог его знает. Я на своем хакинтоше особых проблем с HFS+ не заметил

Дык и с EXT2 проблем нет. И с UFS, и с FAT32.

>а ZFS - вкусно конечно, но что-то с ней не так. Под win32 её нет, так что
>кросплатформенная ОС как была VFAT, так и осталась

Под win32, если вы не заметили, вообще ничего нет.

>Linux - так FUSE штука хорошая, но я ей как-то не сильно доверяю.

FUSE - тормозной костыль.

>*BSD что-то как-то тоже не шатко не валко.

В BSD все как раз замечательно.

>работа, там надежность - а маку оно зачем? Ну грохнется HFS+
>с горой хлама их инета понатянутого, ну переформатировали - переустановили и
>всё.

Угу, характерный для проприетарщины подход к надежности. Знакомо.

>в нете, диски оптические... Так что сомнительная вкусность для дома-то. Разве
>что беспроблемное увеличение дискового объема.

"Разве что". "Разве что" единственная правильная из существующих железных и софтовых реализация RAID, офигенная надежность и производительность, снапшоты, удобная организация томов и куча других плюшек.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено angra , 02-Ноя-09 15:41 
>Дык и с EXT2 проблем нет. И с UFS, и с FAT32.

Скорость это тоже проблема. Но ZFS в этом плане ничем не поможет.

>Под win32, если вы не заметили, вообще ничего нет.

А как же куча версий fat и ntfs плохо совместимых друг с другом? ;)

>>Linux - так FUSE штука хорошая, но я ей как-то не сильно доверяю.
>FUSE - тормозной костыль.

Ладно тормоз(хотя для десктопа это незаметно), но почему костыль?

>В BSD все как раз замечательно.

Не следил, там уже научились на zfs писать и с нее грузится?

>"Разве что". "Разве что" единственная правильная из существующих железных и софтовых реализация
>RAID, офигенная надежность и производительность, снапшоты, удобная организация томов и куча
>других плюшек.

Производительность там как раз отвратная. Надежность при смерти винта ровно такая же как и у всех других fs. При сбоях в питании тоже ничем хорошим не выделяется. Остаются снапшоты, но они и без zfs существуют, причем на винде/маке/бсд/линуксе, различается только способ и количество телодвижений конечного пользователя.

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


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 15:50 
>Производительность там как раз отвратная. Надежность при смерти винта ровно такая же
>как и у всех других fs. При сбоях в питании тоже
>ничем хорошим не выделяется. Остаются снапшоты, но они и без zfs
>существуют, причем на винде/маке/бсд/линуксе, различается только способ и количество телодвижений конечного
>пользователя.
>
>ZFS неплохая система для серьезных серверов, но зачем она нужна для Маков?
>Надеюсь перспективы серверного применения MacOSX вы не будете обсуждать.

Вам не кажется, что вы сами себе в этих двух абзацах противоречите?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено angra , 02-Ноя-09 17:22 
Нет противоречия. Вы не замечали, что железо и задачи на десктопе и серверах несколько разнятся. Стоит добавить хотя бы второй винчестер и у ZFS уже появляются преимущества в скорости и надежности перед обычной fs.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 17:31 
>Нет противоречия. Вы не замечали, что железо и задачи на десктопе и
>серверах несколько разнятся. Стоит добавить хотя бы второй винчестер и у
>ZFS уже появляются преимущества в скорости и надежности перед обычной fs.
>

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

Как же ж ее такую можно на сервер, если все так плохо?

Вопрос можно? Вы сами-то ZFS используете, или на слухах Радио ОБС свои утверждения основываете?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено angra , 02-Ноя-09 19:45 
Общались бы мы лично, я бы проговорил медленно и по слогам, может быть несколько раз, ну чтобы дошло. В переписке подобное бессмысленно, так что могу только посоветовать читать предыдущий пост до просветления, так как к сказанному мне нечего добавить, не переходя к ликбезу.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 21:18 
>Общались бы мы лично, я бы проговорил медленно и по слогам, может
>быть несколько раз, ну чтобы дошло. В переписке подобное бессмысленно, так
>что могу только посоветовать читать предыдущий пост до просветления, так как
>к сказанному мне нечего добавить, не переходя к ликбезу.

Если нечего больше сказать - то так честно и признайтесь. А уж ликбез - это для вас проводить надо.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Денис Юсупов , 02-Ноя-09 16:16 
>>Под win32, если вы не заметили, вообще ничего нет.
>
>А как же куча версий fat и ntfs плохо совместимых друг с
>другом? ;)
>

Чем это они плохо совместимы друг с другом?

>>В BSD все как раз замечательно.
>>Не следил, там уже научились на zfs писать и с нее грузится?

Давно уже:
http://wiki.freebsd.org/ZFS
http://wiki.freebsd.org/ZFSOnRootWithZFSboot


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 17:37 
>Скорость это тоже проблема. Но ZFS в этом плане ничем не поможет.

С чего бы? Со сторостью все замечательно. 6 дисков, raidz2 - 300/450 метров запись/чтение, мне кажется отлично. Зеркало - честные 2x скорости одного диска на запись, 1x скорости одного диска на чтение.

>Ладно тормоз(хотя для десктопа это незаметно), но почему костыль?

Потому что в userspace - кошмарный оверхед на любую операцию.

>Не следил, там уже научились на zfs писать и с нее грузится?

Там писать на ZFS умели всегда, а грузиться научились уже с год назад.

>Производительность там как раз отвратная.

См. выше.

>Надежность при смерти винта ровно такая же как и у всех других fs.
>При сбоях в питании тоже ничем хорошим не выделяется.

Нет, надежность много выше из-за чексумм, отсутствия write hole (по сравнению со многими софтварными рейдами) и возможности для критичных данных явно указать, что их надо хратить в N копиях.

>Остаются снапшоты, но они и без zfs существуют, причем на винде/маке/бсд/линуксе

_Мгновенные_ снапшоты, клоны, и инкрементальный send/receive.

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

ZFS неплохая система для всего


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено angra , 02-Ноя-09 20:14 
>С чего бы? Со сторостью все замечательно. 6 дисков, raidz2 - 300/450
>метров запись/чтение, мне кажется отлично. Зеркало - честные 2x скорости одного
>диска на запись, 1x скорости одного диска на чтение.

Как часто вы видите на маках хотя бы два диска? Или вы забыли о чем топик?


>>Ладно тормоз(хотя для десктопа это незаметно), но почему костыль?
>Потому что в userspace - кошмарный оверхед на любую операцию.

1) не сам userspace, а переключение между kernel/user
2) для дисковых операций это не так уж и заметно, особенно на десктопном использовании.
3) с тормозами я не спорил, но почему костыль? Как раз наоборот очень даже элегантное решение

>Нет, надежность много выше из-за чексумм, отсутствия write hole (по сравнению со
>многими софтварными рейдами) и возможности для критичных данных явно указать, что
>их надо хратить в N копиях.

Если винт один(всего один, никаких raid) и он умер все это будет до женского полового органа.

>_Мгновенные_ снапшоты, клоны, и инкрементальный send/receive.

Вы действительно думаете, что такие снапшоты это изобретение ZFS и такого нигде раньше не было и сейчас нет? Вы очень ошибаетесь, почитайте хотя бы http://en.wikipedia.org/wiki/Snapshot_(computer_storage).

>ZFS неплохая система для всего

Это называется панацея, человечество ими обманывается с незапамятных времен. В IT области наверное это происходит чаще всего, минимум раз в год заявляют, что технология X хороша для _всего_. ZFS всего лишь совместила в себе LVM, RAID и FS, комбайн получился знатный( хотя мне больше по душе unix-way), но совать его бездумно во все щели не стоит.



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено iZEN , 02-Ноя-09 21:05 
>>ZFS неплохая система для всего
>
>Это называется панацея, человечество ими обманывается с незапамятных времен. В IT области
>наверное это происходит чаще всего, минимум раз в год заявляют, что
>технология X хороша для _всего_. ZFS всего лишь совместила в себе
>LVM, RAID и FS, комбайн получился знатный( хотя мне больше по
>душе unix-way), но совать его бездумно во все щели не стоит.

Небольшое впечатление от ZFSv13 на FreeBSD 8.0-RC2:
- отъём оперативной памяти 500МБ сразу и 2,5ГБ потом по мере работы при наличии 6ГБ ОЗУ;
- сверхмедленный запуск Firefox/Thunderbird и других нативных Gtk-приложений — порядка 30 секунд;
- сверхбыстрый запуск некоторых Java-приложений — сплэш RSSOwl появляется на пару секунд и тут же исчезает, однако о Eclipse такого не скажешь (обычное время старта) — непонятно.
- Conky неверно отображает информацию о свободном пространстве для каталогов — по идее, оно должно быть одинаковым, так как все ФС каталогов находятся в одном пуле. GNOME System Monitor на этот счёт не врёт.
- ну и общая латентность системы как следствие применения небыстрых ноутбучных винчестеров (в режиме zpool mirror), среднее время доступа у которых порядка 15...17мс.



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 21:22 
>>С чего бы? Со сторостью все замечательно. 6 дисков, raidz2 - 300/450
>>метров запись/чтение, мне кажется отлично. Зеркало - честные 2x скорости одного
>>диска на запись, 1x скорости одного диска на чтение.
>
>Как часто вы видите на маках хотя бы два диска? Или вы
>забыли о чем топик?

Видимо втречается, раз даже вот такую штуку сделали:

http://www.ifixit.com/Apple-Parts/9-5-mm-Optical-Bay-SATA-Ha...

А уж внешние то подключить - вообще на раз-два...


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 21:34 
>Как часто вы видите на маках хотя бы два диска? Или вы забыли о чем топик?

Во всех двух маках, которые я видел, было два диска.

>>>Ладно тормоз(хотя для десктопа это незаметно), но почему костыль?
>>Потому что в userspace - кошмарный оверхед на любую операцию.
>
>1) не сам userspace, а переключение между kernel/user

Разумеется.

>2) для дисковых операций это не так уж и заметно, особенно на
>десктопном использовании.

Ой ли. Не мудрено, что ZFS у вас стал медленным.

>3) с тормозами я не спорил, но почему костыль? Как раз наоборот
>очень даже элегантное решение

Для свистоперделок типа ftpfs и sshfs - да. Для честных ФС, где важна производительность это полная ересь.

>Если винт один(всего один, никаких raid) и он умер все это будет
>до женского полового органа.

И что? От ФС тут ничего не зависит. А от дохлых секторов (в случае copies>1), и silent data corruption (чексуммы) ZFS спасет.

>Вы действительно думаете, что такие снапшоты это изобретение ZFS и такого нигде
>раньше не было и сейчас нет? Вы очень ошибаетесь, почитайте хотя
>бы http://en.wikipedia.org/wiki/Snapshot_(computer_storage).

Где я говорил что снапшоты - изобретение ZFS? Кроме того, мы говорим о маках - какие-кикие там на HFS+ снапшоты?

>Это называется панацея, человечество ими обманывается с незапамятных времен.
>В IT области наверное это происходит чаще всего, минимум раз в год заявляют, что
>технология X хороша для _всего_.

Ну чтобы не выглядеть глупо вы могли бы привести пример, где она не хороша, и почему.

>ZFS всего лишь совместила в себе LVM, RAID и FS

"Всего лишь" до нее это так эффективно никто не делал, хотя идея соединения LVM, RAID и FS очевидна.

>комбайн получился знатный( хотя мне больше по
>душе unix-way), но совать его бездумно во все щели не стоит.

Человечество также клеит ярлыки с незапамятных времен. В ZFS нет никакого отступления от unix-way, она делает именно то, что должна делать файловая система. Вы путаете unix-way с нагромождением дырявых абстракций.

Вы же не против того, что поддержка снапшотов или журнала является частью ФС? По вашему unix-way журнал и снапшоты вообще дело LVM, потому что это позволяет использовать их с любой ФС, и вообще без ФС. Фигли там - клепай RAID, поверх слой для поддержки чексумм, поверх LVM, поверх слой для снапшотов, поверх журнал, поверх сжатие, потом шифрование, поверх всего этого разметка и, наконец, ФС - комбинируй в любой последовательности.

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


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено angra , 03-Ноя-09 18:29 
>Во всех двух маках, которые я видел, было два диска.

В тех семерых, что встречались мне было по одному. :)

>Ой ли. Не мудрено, что ZFS у вас стал медленным.

А ZFS здесь причем? Или вы думаете, что это его я использую под FUSE?

>Для свистоперделок типа ftpfs и sshfs - да. Для честных ФС, где
>важна производительность это полная ересь.

Странный вы человек, ну так не используйте FUSE там, где нужна производительность, оно не для этого. И без FUSE в линуксе богатый выбор ядерных драйверов fs.
Вот cd/dvd/flash тоже уступают винчестерам по производительности, а винчестеры уступают RAM, а RAM процессорному кешу. Так что все кроме процессорного кеша это костыль?
Или может в терминах не сходимся? В моем понимании костыль - это корявое(плохое, не качественное, потенциально опасное, не надежное) временное решение, а в вашем?

>И что? От ФС тут ничего не зависит.

О чем я и говорил

>Где я говорил что снапшоты - изобретение ZFS? Кроме того, мы говорим
>о маках - какие-кикие там на HFS+ снапшоты?

Там есть time machine, для конечного пользователя выглядит примерно так же. Ну а на серверах снапшоты давным давно используются, причем для всех OS, так что zfs тут ничего нового не принесла.

>Ну чтобы не выглядеть глупо вы могли бы привести пример, где она
>не хороша, и почему.

Элементарно, ватсон. Поставьте ее на дискету/cd/dvd/blue-ray :)
Хотите менее тривиальный пример? Пожалуйста, flash и ssd винчестеры, для них нужны fs минимизирующие количество перезаписей на каждый блок.

>"Всего лишь" до нее это так эффективно никто не делал, хотя идея
>соединения LVM, RAID и FS очевидна.

А так ли это нужно? Железный RAID она не переплюнет, гибкость LVM или GEOM тоже.

>Человечество также клеит ярлыки с незапамятных времен. В ZFS нет никакого отступления
>от unix-way, она делает именно то, что должна делать файловая система.
>Вы путаете unix-way с нагромождением дырявых абстракций.

У нас есть несколько заменяемых компонентов, каждый из которых хорошо делает свою работу. Вместо них предлагается один, который хорошо сочетает в себе их всех, хотя по отельным параметрам может каждому из них проигрывать. Данный комбайн как и многие другие весьма полезен, спору нет, но где здесь unix-way?

Еще раз для ясности, ZFS хороший комбайн, у него есть много сфер применения, вот только не надо делать из него панацею.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 21:39 
> ZFS всего лишь совместила в себе
>LVM, RAID и FS, комбайн получился знатный( хотя мне больше по
>душе unix-way), но совать его бездумно во все щели не стоит.

Апологету юниксвея никто не запрещает засунуть под ZFS любой менеджер томов на выбор, вон чуваки даже аналог линуксового device mapper под OpenSolaris с нуля пишут:

http://hub.opensolaris.org/bin/view/Project+devmapper/

Только вот вопрос - нафига? Проведите ликбез, а?



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Bulgarin , 03-Ноя-09 01:48 

>>В BSD все как раз замечательно.
>Не следил, там уже научились на zfs писать и с нее грузится?

# mount
z80pool on / (zfs, local, noatime)

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

после некоторого скептичного тестирования zfs - применил и на нотнике.
c ufs2 на zfs, и не плакаю.
удобная, падла. особенно нравится перенос точек монтирования с диска на диск.

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

ну конечно, не все радужно, есть нечто что не так как в сказке, но так никто и не обещал.



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Aleksey Salow , 03-Ноя-09 02:18 
>про снапшоты вообще молчу - сделал снапшот, потестировал софтинку,
>потом откат обратно - и все как було.

Снапшоты это вообще мегавещь. Перед обновлением системы делаем clone и promote, накатываем апдейт, бутаемся. Если что-то не так - у нас всегда есть старая рабочая fs и к ней можно вернуться без проблем (и прямо с неё даже бутнуться). Да и бекапы через send/receive по крону - прям как time machine у маков, причём всё нативно и красиво.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 05-Ноя-09 16:05 
>но зачем она нужна для Маков?

1) У них есть серверная ос. Я правда не видел тех кто ее использует, но...
2) Хотя-бы чтобы машину времени не совсем уж через %#пу делать?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 17:02 
>Под win32 её нет,

Если вы разуете глаза, под Win32 - НИХРЕНА нет! Ну, есть средне-паршивенькие драйвера EXT2.И не более того. Дело в том что MS хотел бабла за IFS SDK. Ну и это сыграло дурную шутку - они теперь по части ФС в полной заднице. В виндовсе наверное самый отстойный выбор из всех современных операционок. Вы можете выбрать из двух (ну ладно, двух с половиной) файловых систем. И все - с дизайном хренадцатилетней давности.

>так что кросплатформенная ОС как была VFAT, так и осталась,

А зачем мне кроссплатформенность на дисках которые привинчены в мой системник, строго говоря? А привязываться к FAT с его лимитом в 4Г на размер файла и тормозами уныло, я для интероперабельности с виндой EXT-2 использую, он хотя-бы не такой дикий тормоз и лимит в 4Г там не долбит.

>Вот и получается - в соляре вкусно, но только в соляре.

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

>а маку оно зачем? Ну грохнется HFS+ с горой хлама их инета понатянутого,
>ну переформатировали - переустановили и всё.

А затем что в случае простой ФС, допустим писали вы месяц прогу, колотили неделю реферат, или там еще какая фигня. А тут вдруг сдуру затерли полфайла да не посмотрев сохранили его. Схватились за бошку. Так и так - попадалово, дескать. А что делать? Правильно - нечего. А версионник может просто и естественно откатиться на прошлую версию и - нет проблем. При том - он просто так работает и в идеале для этого ему вообще делать ничего не надо, кроме как забить на последние логи. Какое-то подобие можно и на иных ФС сделать, но куда как более похабно, геморройно и неэффекивно. Не говоря о том что версионник по идее журналирует и данные и метаданные так что при сбое файлы могут всегда оказываться в вменяеых состояниях а вот запись при этом делается практически на уровне скорости не-журналирующей ФС, чисто в силу особенностей.

>Свое-то каждый все равно бакапит на что-то более надежное.

Вот только возврат к старой версии как бы проще и быстрее возврата к бэкапу. Представляете себе файл на гиг? Забить на логи каких-то изменений в нем на уровне ФС и увидеть его каким он был без этих изменений - *моментально*. А вот перезаписать файл на гиг из архивной копии - некая возня.

>Так что сомнительная вкусность для дома-то.

Да, конечно, возможность отката необдуманных изменений ФС одним махом - совсем не нужна. При том в нормальной реализации это не требует никаких особых действий и получается просто потому что ФС так работает.

>Разве что беспроблемное увеличение дискового объема. Так тоже вопрос.
>Поколение бьющее диск на тома типа "System", "Software", "Video", "Photo", "Hlam"
>еще не умерло, и пока не умрет данный плюс ZFS на десктопе весьма сомнителен.

Ага, зато круто получается когда допустим в Video оно уже не лезет, а в Software допустим полно места. А потом в систему добавляется еще диск, и там создается какоенить галимное Video2 и т.п. чтоб их не путать, etc :).Это вместо того чтобы просто добавить диск и поиметь больше свободного места в своем "Video" вообще без левого траха.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Dyr , 02-Ноя-09 17:13 
> А версионник может просто и естественно откатиться на прошлую версию
>и - нет проблем. При том - он просто так работает
>и в идеале для этого ему вообще делать ничего не надо,
>кроме как забить на последние логи. Какое-то подобие можно и на
>иных ФС сделать, но куда как более похабно, геморройно и неэффекивно.

Справедливости ради, в MacOS вроде есть что-то подобное, "Time machine" называется. Не?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 18:05 
>Справедливости ради, в MacOS вроде есть что-то подобное, "Time machine" называется. Не?

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


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено letsmac , 02-Ноя-09 19:15 
>>С версионниками оно получается просто, быстро и естественно

В Novell такое видел в 1998, с клиентами от доса до NT и линухов. Действительно помогает от идиотов.

>>вместо того чтобы сразу сделать не через *опу.

TimeMachine в macos хватает за глаза для восстановления файлов. Без всякого геммороя с настройкой пулов. Работает правда долговато с первым бэком, зато с TM можно полностью восстановить машину - даже после падения с 5-го этажа.

ЗЫ: У оперсорщиков все инетерсно через чего сделано, если обновление ядра заявит, что модули ему не уже подходят, а весь toolchain лежит на расширяемом пуле.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 22:07 
>Действительно помогает от идиотов.

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

>TimeMachine в macos хватает за глаза для восстановления файлов. Без всякого геммороя
>с настройкой пулов.

Именно настройка пулов - да, на любителя. Только знаете, когда дома вот так вот несколько дисков по терабайту-полтора - я уже начинаю подумывать о том что классический подход к управлению ФС "управлять не будем" - начинает всасывать все-таки. А то копировать терабайт данных - это как бы долго, нудно и утомительно.

>Работает правда долговато с первым бэком, зато с TM можно полностью
>восстановить машину - даже после падения с 5-го этажа.

А если еще и в железобетонном бункере жить, на глубине километр - тогда и внезапно прилетевший метеорит вас не испугает, а также вы смоежете пережить дружественный обмен ядерными ракетами с США и все такое :).

>ЗЫ: У оперсорщиков все инетерсно через чего сделано, если обновление ядра заявит,
>что модули ему не уже подходят, а весь toolchain лежит на
>расширяемом пуле.

Ну и чо, прикольно :D. Как там у вас полагается то? First Infinite Loop? Ну вот кажется это оно :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 03-Ноя-09 16:44 
>Справедливости ради, в MacOS вроде есть что-то подобное, "Time machine" называется. Не?

Это убожество на уровне echo "0 0 * * * root tar cvfz /time-machine.tar.gz /" > /etc/crontab


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 20:54 
>Это убожество на уровне echo "0 0 * * * root tar cvfz /time-machine.tar.gz /" > /etc/crontab

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



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 17:40 
>.Пингвиноиды будут накрайняк пользовать FUSE, но чтобы пользоваться реально и всерьез, имхо - сделают btrfs.

Или ZFS портируют: http://kqinfotech.wordpress.com/


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 17:48 
>Или ZFS портируют: http://kqinfotech.wordpress.com/

О-о-о, я давно это предрекал. Нашлись таки вменяемые люди. А про GPL vs. CDDL могли бы проще написать - нам подтереться GPL, мы хотим ZFS под Linux и точка, и это было бы очень правильно.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 18:08 
>Или ZFS портируют:

Да хрен бы с ним, с ZFS-ом, это достаточно странный дизан от санок. Бтр будет лучше. А zfs останется тем кто сам по части фС сделать нифига не может. Где-то так. Злобно называть вещи своими именами, но это вроде бы честно, yeah?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 19:22 
>>Или ZFS портируют:
>
>Да хрен бы с ним, с ZFS-ом, это достаточно странный дизан от
>санок. Бтр будет лучше.

Ключевое слово здесь - "будет". Но никто не знает когда. Пока то что есть - использовать нельзя. В то время как ZFS уже есть здесь и сейчас. И становится лучше с каждым днем. Вот вчера/сегодня дедупликация появилась.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено vitek , 02-Ноя-09 20:08 
не надо так обобщать про "никто не знает". вот timeline к версии btrfs 1.0 - http://btrfs.wiki.kernel.org/index.php/Development_timeline
с ведра 2.6.32.

>Вот вчера/сегодня дедупликация появилась.

ах, да!
выше уже писали.... а отключить её можно?
а то на десктопе ещё и бэд-блоки бывают.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 21:26 
>не надо так обобщать про "никто не знает". вот timeline к версии
>btrfs 1.0 - http://btrfs.wiki.kernel.org/index.php/Development_timeline
>с ведра 2.6.32.

Ну и где там написано, когда она будет пригодна к сколько-нибудь серьезному использованию?

>>Вот вчера/сегодня дедупликация появилась.
>
>ах, да!
>выше уже писали.... а отключить её можно?
>а то на десктопе ещё и бэд-блоки бывают.

Ее можно не включать. На десктопе даже на одном диске можно использовать механизм дубль-блоков, чтобы от этих самых бэдов защититься.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 21:02 
>Ключевое слово здесь - "будет". Но никто не знает когда. Пока то
>что есть - использовать нельзя. В то время как ZFS уже
>есть здесь и сейчас.

Дык где он под линухом то есть? На сайте этих парней написано как у них все плохо, при том плохо - на более другом уровне чем у btrfs, оно даже на таком уровне пока не ездит :)

Что-то работающее AFAIK есть под fuse но здесь и сейчас им будут пользоваться только кому приперло что-то zfs-ное прочесть. Остальным это fuse-шное тормозилово никуда не впилось а ядерный порт в состоянии похуже БТР-а пока что, если верить их же сайту. И как бы еще вопрос что там будет быстрее. Вон бздуны несколько лет портировали zfs и оно только недавно стало более-менее работать без чрезмерных приключений на свою задницу. И то готов поспорить, что буквально шаг в сторону от стандартных сценариев и это их "готовое для продакшна" решение устроит вам такой сюрприз что мало не покажется. Помню я как EXT4 был готовым для продакшна, ага, но баги находились достаточно колоритные :D. С чего вы взяли что у этих получится портирование и обезглючка сильно быстрее? Такие монстрильные ФС отладить за месяц - невозможно.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Moosh , 03-Ноя-09 19:14 
>>Или ZFS портируют:
>
>Да хрен бы с ним, с ZFS-ом, это достаточно странный дизан от
>санок. Бтр будет лучше. А zfs останется тем кто сам по
>части фС сделать нифига не может. Где-то так. Злобно называть вещи
>своими именами, но это вроде бы честно, yeah?

БТР Будет лучше! ZFS тоже с годами будет еще лучше, чем уже есть.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 21:06 
>БТР Будет лучше! ZFS тоже с годами будет еще лучше, чем уже есть.

БТР на уровне дизайна лучше ZFS-а.Уже сейчас.Тем более что по итогам первых проб, его дизайн дисковых структур 2 раза меняли. Пока его никто в продакшн не юзает - это можно себе позволить :).А кто будет именно развивать ZFS при том на уровне такой вот масштабной стройки - не понятно. Бздуны вон кой-как его только-только прикрутили за столько лет. Солярщики?Пока их там окрал схавает и переварит, пройдут годы.Макинтошники вообще вон хвост трубой.Пингвиноиды этим активно заниматься не будут т.к. лицензия.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 02-Ноя-09 17:23 
>*BSD что-то как-то тоже не шатко не валко.

В 8.0  же обещали, что ZFS будет production ready.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Dyr , 02-Ноя-09 19:48 
>>*BSD что-то как-то тоже не шатко не валко.
>
>В 8.0  же обещали, что ZFS будет production ready.

Она уже в семёрке production ready, только в семёрке она ZFSv.8, а в 8.0 ZFSv.13


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено anonymous , 02-Ноя-09 20:22 
ZFS filesystem version 6 в FreeBSD 7.2
Но и она нифига не продакшен реди.
иди залогинься на свой зюзероутер и проверь.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено anonymous , 03-Ноя-09 10:15 
zfs там production-ready, просто пора выкинуть свой краснознамённый ордена ленина 3-ей степени пень-2 с 384 метрами склероза и использовать железо хотя бы 2-х летней давности

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 05-Ноя-09 16:11 
>В 8.0  же обещали, что ZFS будет production ready.

EXT4 вон тоже обещали, а как почитаешь их ченжлоги... Думаете, эти чем-то лучше? Черта с два, все програмеры одинаковы :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено fd , 02-Ноя-09 10:45 
находятся ведь ещё энтузиасты, к-ые делают что-то для Apple. Помоему более неблагодарной и дурной конторы поискать ещё надо.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 14:30 
Энтузиасты это делают прежде всего для себя и тех людей, у кого есть Apple.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено IdeaFix , 02-Ноя-09 11:23 
Самая вкусная фишка ZFS - это даже не столько "резиновость" разделов и бОльшая, по сравнению с тем же LVM скорость на сложных конфигурациях... имхо, всётаки самаая главная фишка - cvs на уровне файловой системы. Тоесть, можно запросто на raid1 в домашних условиях получить как физическое зеркалирование, так и возможность отката к какому-то заранее сохраненому состоянию системы.

В BSD (если говорить о фре семерке) всё неплохо с сабжем. А с маками вс скорее всего гораздо проще - если использовать ZFS так, чтобы она предлагала хоть какие-то приемущества перед конкурентами, необходимо иметь очень мощный процессор (чего только снапшоты состояния на лету стоят), а маки в большинстве своём не наспологают обширными дисковыми массивами, или даже просто дисками и процессоры у них в большинстве своём весьма бюджетные. По-моему зфс для ширпотреба (основной сферой для мака) ещё рано. Практически все ноутбуки и ущербные десктопы (аймак, мак мини) в зфс не нуждаются, а стоит ли ради остального напрягаться? Фряшники оформят до конца, тогда может и апля подтянется, а пока... что зря человекочасы тратить?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 15:47 
>имхо, всётаки самаая главная фишка - cvs на уровне файловой системы.

Только это не CVS на уровне файловой системы называется, а сервисы по управлению данными.

>В BSD (если говорить о фре семерке) всё неплохо с сабжем. А
>с маками вс скорее всего гораздо проще - если использовать ZFS
>так, чтобы она предлагала хоть какие-то приемущества перед конкурентами, необходимо иметь
>очень мощный процессор (чего только снапшоты состояния на лету стоят),

Нука-нука, с этого места поподробнее пожалуйста. Насколько мощный процессор нужен для создания снапшота на лету, если он содается за время O(1)?

> а
>маки в большинстве своём не наспологают обширными дисковыми массивами, или даже
>просто дисками и процессоры у них в большинстве своём весьма бюджетные.

Core 2 Duo под 3 ГГц - бюджетный процессор? Маки без диска - такое бывает?

>По-моему зфс для ширпотреба (основной сферой для мака) ещё рано. Практически
>все ноутбуки и ущербные десктопы (аймак, мак мини) в зфс не
>нуждаются,

Пошел сносить со своего ноутбука ZFS, так как IdeaFix открыл мне глаза, убогому, на то, что она там, оказывается, не нужна.

Вопрос можно? Что вместо ZFS порекомендуете?



"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 17:41 
>cvs на уровне файловой системы.

Это ж надо так версионник назвать...

>очень мощный процессор (чего только снапшоты состояния на лету стоят),

А что там мощным процессором делать? Версионник работает так: все пишется как логи изменений. Поэтому при изменении файла его старый вид вообще не трогается, просто пишется довесок - лог с изменениями. Далее структуры ФС меняются чтобы учитывать что для построения текущего вида файлов надо использовать как старые блоки, так и блоки вон из этого нового лога. Снапшот - это набор метаданных ФС описывающих откуда брать блоки файлов чтобы получить их версию на некий момент времени. Весь этот набор метаданных уже и так есть при штатной работе ФС, т.к. он нужен для построения текущего вида файлов, собссно. Остается лишь волевым решением объявить что вот то что есть сейчас - это снапшот. Сие почти мгновенно и не требует никаких особых действий. Из интересностей - запись по скорости - практически как в не-журналирующей ФС, т.к. все пишется 1 раз. Простое рекавери - т.к. старый вид файла не трогается, при неудаче записи достаточно просто забить на недописанный лог и файл просто окажется в его более старой версии. Возможность отката операций. Просто забиваем на логи которые новее чем Х и ... при чтении видим файл на момент Х. Проблемы у дизайна тоже ессно есть - надо подчищать срач из логов иначе том забьется старыми версиями, ну и фрагментация, т.к. цепочка логов - потенциально склонна к фрагментации.

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

Обычное оправдательное мяукание любителя проприетарщинки оставшегося без вкусной плюшки. Наслаждайтесь тем что за вас как всегда все решили в Эппл и показали вам фигу, ага.Я думаю теперь некоторые понимают почему я не слишком жалую проприетарщиков. Достало вот так же мяукать когда вендор в силу своего монополизма в энный раз фигу покажет :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 02-Ноя-09 19:06 
> и возможность отката к какому-то заранее сохраненому состоянию системы.

у версионных ФС не надо ничего *заранее* сохранять. Там нооброт надо заранее подчищать старые версии, чтоб высвободить место для новых.

Заранее сохранять надо только на ФС, построенных на принципе CoW - ZFS и BTRFS.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено QuAzI , 02-Ноя-09 12:18 
К винде бы её хотябы read only, а то знакомых с MacOS как-то меньше чем виндузятников.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено klalafuda , 02-Ноя-09 12:27 

вы так часто втыкаете серверные винты в виндовые машины? зачем, если не секрет :-?

// wbr


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 17:45 
>К винде бы её хотябы read only,

А микрософт уже опубликовал нашару IFS SDK и документацию? Нет? А кому надо свое бабло вкладывать тогда? Микрософту оно не надо, и так как-нить схаваете. А остальным платить деньги чтобы вас осчастливить не с руки. Так что ждите, ага :). А покуда под винду есть разве что ext2 средне-кривой и довольно тормознутый. Ну и хватит с вас счастья...


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Aleksey Salow , 03-Ноя-09 00:12 
Идиоты на марше?

http://www.microsoft.com/whdc/devtools/ifskit/default.mspx
The IFS Kit is distributed as part of the Windows Driver Kit (WDK).

WDK скачать можно тут: http://www.microsoft.com/downloads/details.aspx?FamilyID=210...


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 04-Ноя-09 01:23 
Да нет, раньше MS реально бабла хотел за IFS SDK когда я вопросом интересовался. А сейчас их на щедрость пробило? Ну простите - а я уже не интересуюсь их платформой. Такая вот фигня :)

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Анонимоус , 02-Ноя-09 14:08 
Очень жаль что в Mac OS X не будет ZFS, обидно, но думаю BTRFS будет там.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 02-Ноя-09 18:12 
>думаю BTRFS будет там.

Ога, с GPL и всеми наворотами :).В другой жизни, Luke. Лучше уж признайте наконец что все кто закладывается на проприетарщиков - пролетают и испытывают такие вот обломы.Или силенок не хватает называть вещи своими именами? :)


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено letsmac , 02-Ноя-09 19:19 
>признайте наконец что все кто закладывается на проприетарщиков - пролетают и

Только с комфортом. OS пролетают с жутким геммороем и собирая парашют на лету, из падающих запчастей:-) Когда на линухах начнёт работать больше 3  игр и хотя бы 80 % оборудования будет вставать без плясок с ядром - тогда будете гонять.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено anonymous , 02-Ноя-09 23:23 
> хотя бы 80 % оборудования будет вставать без плясок с ядром - тогда будете гонять.

А поставьте-ка мне Mac OS X на AMD Opteron.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено anonymous , 03-Ноя-09 10:20 
>> хотя бы 80 % оборудования будет вставать без плясок с ядром - тогда будете гонять.
>
>А поставьте-ка мне Mac OS X на AMD Opteron.

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

З.Ы. Иди поставь линух 2.6.х на пень-1


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 03-Ноя-09 17:17 
>З.Ы. Иди поставь линух 2.6.х на пень-1

Открой для себя дебиан.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Sergey , 06-Ноя-09 17:50 
>>> хотя бы 80 % оборудования будет вставать без плясок с ядром - тогда будете гонять.
>>
>>А поставьте-ка мне Mac OS X на AMD Opteron.
>
>у любой ОС есть список поддерживаемого оборудования, работа на котором гарантирована. На
>оборудовании, не входящем в этот список, ОС работать не обязана.
>
>З.Ы. Иди поставь линух 2.6.х на пень-1

А чем это отличается от установки на C2D?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 22:17 
>Только с комфортом. OS пролетают с жутким геммороем и собирая парашют на
>лету, из падающих запчастей:-)

В итоге правда поскольку падение продолжается долго (софт пишут десятилетиями) - у чуваков за это время выходит непозорный ракетоплан, хоть для управления им и приходится поучиться слегонца :). Тем временем проприетарщики лечат "заплати $XXX или падай без парашюта сколько влезет". Спасибо, но я лучше поучусь управлять ракетопланом, чем буду покупаться на дешевый шантаж.


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено paranormal , 02-Ноя-09 14:56 
Чего вы расхоливалирись. ZFS - реально удобнее, логичнее, понятнее - и не важно с чем сравнивать. Сейчас у меня LVM - после zfs он кажется мне маргинальным.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено ы , 02-Ноя-09 15:13 
если у линуксоидов чего-то нету, значит это им не надо, это не труЪ и тд, рубили всю жизнь дрова топором, так и пусть рубят, а остальные пилораму будут использовать :)

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено User294 , 03-Ноя-09 22:18 
У линуксоидов своя пилорама строится, хоть и другой системы :)

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено anonymous , 02-Ноя-09 15:22 
Sun наверное сами офигели от своих же заморочек с лицензией)) То есть компания Apple, для которой ничего не стоит купить и использовать любую проприетарную разработку - и те отказались от использования ZFS именно по причине лицензии.

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Anon Y Mous , 02-Ноя-09 15:39 
>Sun наверное сами офигели от своих же заморочек с лицензией)) То есть
>компания Apple, для которой ничего не стоит купить и использовать любую
>проприетарную разработку - и те отказались от использования ZFS именно по
>причине лицензии.

Вас послушать, так вы при этих переговорах присутствовали. Откуда дровишки, что отказались  именно из-за того, что ZFS выпущена в открытый доступ по лицензии CDDL?


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено аноним , 02-Ноя-09 17:38 
Вероятно тут что-то описывается

https://www.opennet.ru/opennews/art.shtml?num=23969

а там ссылки на заявление и описание возможных причин
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-Octob...
http://www.macrumors.com/2009/09/01/lack-of-zfs-file-system-.../


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Аноним , 02-Ноя-09 19:11 
>http://mail.opensolaris.org/pipermail/zfs-discuss/2009-Octob...

ну так это не вина CDDL


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Dorlas , 02-Ноя-09 17:35 
>Sun наверное сами офигели от своих же заморочек с лицензией)) То есть
>компания Apple, для которой ничего не стоит купить и использовать любую
>проприетарную разработку - и те отказались от использования ZFS именно по
>причине лицензии.

Читать тут:
http://developers.sun.ru/content/view/283/31/

Мало чем отличается от BSD/GPL...найди 10 отличий...


"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено vitek , 02-Ноя-09 18:19 
вот молодец! и бзд, и гпл, и сддл - всё в одну кучу. красота!
я бы ещё еулу для комплекта докинул бы. :-D

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Moosh , 03-Ноя-09 19:09 
Эту куча называется Open Source Licences, http://www.opensource.org/licenses

"Энтузиасты взяли в свои руки реализацию ZFS для MacOS X"
Отправлено Dorlas , 19-Дек-09 18:44 
>вот молодец! и бзд, и гпл, и сддл - всё в одну
>кучу. красота!
>я бы ещё еулу для комплекта докинул бы. :-D

Специально для тех, кто в танке - EULA в списке там есть, ничего докидывать не нужно...


"что за митинг?"
Отправлено anonymous , 03-Ноя-09 10:11 
не понял, почему линуксоидов так волнует судьба проприетарной ФС на проприетарной ОС


"что за митинг?"
Отправлено iav , 03-Ноя-09 17:28 
>не понял, почему линуксоидов так волнует судьба проприетарной ФС на проприетарной ОС

Наверное, потому, что толпы линуксойдов давно сидят на маках, а zfs — открытая FS.