ZFS: почему её нельзя портировать на Linux?

> Если компьютер выключен то они берутся с другого и пишутся туда. Машины синхронизируют данные.

AFS, CodaFS. Но для этого клиентские машины должны быть под Linux. Ну или loop-over-smbfs => чтение всё равно через сервер.

А если клиенты под Windows (то есть раздавать только через SMBfs), то я свою дипломную в институте на эту тему писал (вкратце: через libsmbclient делается индексирование всего, что есть на машинах + делается резервное копирование того, что меньше 3 копий + поисковик)

На практике в 90% случаев достаточно что-то вроде crontab + rsynс -auv

> . Но для этого клиентские машины должны быть под Linux.

OpenAFS есть и под винду.

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

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

Насколько я понимаю AFS и CODA это когда есть дерево каталогов, каталог d1 лежит на машине 1, d2 на машине2... Или я не прав? А хочется чтоб файл лежал физически на 5-6 машинах. Чтение можно формить паралельно - запись синхронно. Сама идея заключается в том, что 1) Если выключена машина или 2, то остаются 3 рабочих и с ними и происходит работа. Когда отключенные включатся - они синхронизируют свое зеркало с остальными 3-мя. итго у меня 71 компьютер с 160Gb дисками. Если свободно на дисках по 100Gb, и разбить компьютеры (для каждого файла разбитие уникальное) по 5 штук (ну и пусть все 5 выключены - ошибка чтения/записи. в 99% времени в организации все машины работают, а по ночам эти данные не нужны. Зато я получаю полтора терабайта пространства, без мыслей о резервном копировании и надежность большая.

Есть специальные кластерные ФС - lustrefs и pvfs(2). Они именно что размазывают файл по кластеру. Но насколько они устойчивы к выходу из строя отдельных узлов - не знаю (вроде, для типичного применения этих ФС в вычислительных кластерах не требуется ).

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

>Предсказывать будущее неблагодарное занятие.

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

Говоря о переспективах роста нынешних FS мы уже предсказываем количественность, а не качественность роста объёмов носителей. А их рост - совершенно предсказуем.

rw узел AFS может иметь множество синхронизированных с ним r- узлов. Автоматически становится rw узел ro по моему не умеет. более того приоритет при автоматическом выборе монтирования в клиенте выбирает r- узел в первую очередь.

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

можно сделать блочно реплицированное устройство, но что то в голову сразу не приходит как оно может работать именно в заказанной конфигурации. Это какой то райд5 с избыточностью в 50% от кол-ва блочных устройств должен получится.

Жаль, но помоему это перспективная штука. Особенно во всяких домовых сетях, где куча хомяков держат у себя на машине копии видео и прочих mp3.... Да и в крупных организациях до 80% объемов проставивает.

Несерьезно это.

Вот когда zfs осилит 256 бит, тогда и поговорим. А так ограничение на объем все равно остается...

> Вот когда zfs осилит 256 бит, тогда и поговорим.

Лучше 640. 640-битной Фс хватит всем.

> Вот когда zfs осилит 256 бит, тогда и поговорим.

Всё равно несурьёзно. Давно пора юзать длинные числа для индексов и размеров! :)

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

ReiserFS и XFS на конкурентов мало похожи. Скорее у них разный круг задач. При правильно использовании оба имеют много приемуществ.

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

Я знаю, что это ничего не доказывает,
но буквально несколько дней назад
в репозитории EVMS были сделаны некоторые
изменения, в частности, как я понял,
залатаны некоторые баги.

http://evms.cvs.sourceforge.net/evms/evms2/engine/

Все таки непонятно.

Если zfs, это один большой флакон, куда вошло все необходимое (db,fs,lvm,dump/restore etc), то почему не добавили свой zчат и zssh?

Я что, должен передавать дампы fs на другую машину без предварительной консультации с админами и через сторонние утилиты?

А если zfs модулен, то могу ли я создать zpool устройств и создать на нем, например, более подходящуюю к конкретным условиям файловую систему, например, jfs или xfs?

А вот выбор 128 бит, как раз не выглядит чрезмерным. К моменту, когда zfs можно будет пользоваться, на рынке уже будут такие устройства хранения данных, что и 256 бит не будут выглядеть чрезмерным запасом...

Да и идея писать новые данные только на новое пустое место выглядит довольно футуристично. Когда еще появятся такие объемы памяти?

> А если zfs модулен, то могу ли я создать zpool устройств и создать на нем, например, более подходящуюю к конкретным условиям файловую систему, например, jfs или xfs?

Тогда тебе придётся указывать размер каждой ФС и это будет LVM. Нельзя приготовить омлет, не разбив яйца. ;)

> ГетЗеФактс от сан.
нну, должность Виктора Латушкина обязывает, что не отменяет его хороших знаний как инженера (в прошлом).

Простите, Господа, что встреваю в столь высокоинтеллектуальный спор, но мы до сих пор в Linux не имеем 100% надёжного механизма записи на FFS/UFS.

imho - появление zfs можно расценить наверное как очередной аргумент в выборе платформы. опять же, если бы был порт на OpenBSD - то можно было бы серьёзно задуматься как минимум о портировании на Linux, а так - разговор ни о чём (кроме как об очередной "фишки" в лицензировании от Sun).

в целом - да, интересная FS, только вот сомнения грызут о смысле её пользования при наличии хардовых raid решений.

> но мы до сих пор в Linux не имеем 100% надёжного механизма записи на FFS/UFS.

И на sys5fs! Позор, я щитаю.

>Тогда тебе придётся указывать размер каждой ФС и это будет LVM. Нельзя приготовить омлет, не разбив яйца. ;)

Ну почему. Хотя бы создать весь пул на xfs. Модульность в том и состоит, что можно заменить один модуль другим.

но в целом да, речь идет о том, что lvm наращивает уже существующие проверенные и работоспособные возможности дополнительным функционалом, а zfs - нет.

в домовых сетях используется DC++ или торрент какой-нить
может это и есть решение?

в домовых сетях используется DC++ или торрент какой-нить
может это и есть решение?

>А если zfs модулен, то могу ли я создать zpool устройств и создать на нем, например, более подходящуюю к конкретным условиям файловую систему, например, jfs или xfs?

AVL2 - ой не надо желчи - свои же трусы и прожгешь :)
Для таких вещей в ZFS предусмотрено рав волюме емулэйшен - так что теоретически - сможешь :)

PS: На офсайте все вполне доступным английским и с картинками - сходил бы чтоли на посмотреть :)

>но в целом да, речь идет о том, что lvm наращивает уже существующие проверенные и работоспособные возможности дополнительным функционалом, а zfs - нет.
>AVL2

Любитель красивой словесности? :) Ну-ну, у нас и на такое ответ найдется %)

Пока LVM&Ko перекрашивают костыли в другой цвет, ZFS'ники ... цитирую:
ZFS is not an incremental improvement to existing technology; it is a fundamentally new approach to data management. We've blown away 20 years of obsolete assumptions, eliminated complexity at the source, and created a storage system that's (http://www.opensolaris.org/os/community/zfs/)

Ты и тут похоже слил, извини :-)

>Да и идея писать новые данные только на новое пустое место выглядит довольно футуристично. Когда еще появятся такие объемы памяти?
>AVL2

Тупишь? Нужно всего по одному смободному блоку на каждом PV - у тебя если что то юниксовое к примеру 10% root и так заныкано :)

>ZFS is not an incremental improvement to existing technology; it is a fundamentally new approach to data management. We've blown away 20 years of obsolete assumptions, eliminated complexity at the source, and created a storage system that's (http://www.opensolaris.org/os/community/zfs/)

Да, да они изобрели дековский advfs, там тебе и пул дисков (domain) и файловые системы на нем (filesets)

http://www.linux.org.ru/jump-message.jsp?msgid=2389149&cid=2394643

> А если zfs модулен, то могу ли я создать zpool устройств и создать на нем, например, более подходящуюю к конкретным условиям файловую систему, например, jfs или xfs?

Да, можешь. Создаешь volume через `zfs create -V 10G tank/jfs' и потом (на фре в `/dev/zvol/tank/jfs') его форматируешь в нужную тебе фс. Получается старый добрый volume manager с checksum'ами, компрессией, snapshot'ами, клонами и прочими вкусностями. К тому же, если добавить ключик -s к zfs create, то volume не будет резервировать под себя место и те 10G, что в примере выше, будут доступны и другим dataset'ам, получиться sparse volume. У меня, например, на sparse volume храниться swap.

> только вот сомнения грызут о смысле её пользования при наличии хардовых raid решений.

"[ZFS and RAID-Z] putting the data replication knowledge in the filesystem rather than inside an array product yields data integrity you cannot get from an array product," Bonwick said. "Fundamentally, if the data is checksummed inside the array, then anything that happens to that data in transit will not be detected by the checksum."

во первых, есть -m0 для тех фс, где резервировать место для рута не надо.

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

>ZFS is not an incremental improvement to existing technology;

Зашибись. Забудем все наработанное и начнем использовать только zfs?

>it is a fundamentally new approach to data management.

4.2

Это просто монстрик, монолитный кусок кода, реализующий уже давно известные и реализованные другими продуктами возможности.

>We've blown away 20 years of obsolete assumptions, eliminated complexity at the source, and created a storage system that's

Еще через 20 лет, можт и до продакшена дело дойдет... ;)

Тогда уж проще mount -t xfs -o loop /mnt/ext3/xfs.raw /mnt/xfs

>>ZFS is not an incremental improvement to existing technology;
>Зашибись. Забудем все наработанное и начнем использовать только zfs?

см. ниже

>>it is a fundamentally new approach to data management.
>4.2

:) Да я знаю - повезло недолго поработать на альфе/труЁ64/advfs ... но - тут ЛОР или где?! ,)

>Это просто монстрик, монолитный кусок кода, реализующий уже давно известные и реализованные другими продуктами возможности.
>Еще через 20 лет, можт и до продакшена дело дойдет... ;)
>AVL2 **** (*) (10.01.2008 13:31:25)

АВЛ2 - хочешь расскажу тебе быль о том как гдето лет 15 назад народ начал массово переходить с UUCP на сендмыл? И как АВЛ1-ый всем рассказывал о том что шлимыл не нужен и что "Это просто монстрик, монолитный кусок кода, реализующий уже давно известные и реализованные другими продуктами возможности." :))))

>АВЛ2 - хочешь расскажу тебе быль о том как гдето лет 15 назад народ начал массово переходить с UUCP на сендмыл? И как АВЛ1-ый всем рассказывал о том что шлимыл не нужен и что "Это просто монстрик, монолитный кусок кода, реализующий уже давно известные и реализованные другими продуктами возможности." :))))

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

Просто коммутируемые сеансовые каналы сошли на нет, а в онлайне удобнее сендмыл.

Но все это не отменяет того факта, что сендмыл - монстрик, кусок дурнопахнущего кода и вместо него следует использовать exim или postfix...

как ты реализуешь `zfs set copies=10 tank/xfs' работая с обычным файлом? Или битость/не битость данные не важна? Очень весело, если побьются зашифрованные данные...
а скоро шифрование станет доступно из коробки, так что не надо будет `geli init /dev/zvol/tank/secret'

>Если бы Sun действительно было нужно портировать ZFS на Linux, они бы её да-а-вно портировали и перешли бы на двойное лицензирование. ;) О чём это говорит? О том, что Sun пока не хочет распространять ZFS под одной из действительно свободных лицензий.

Это говорит о том, что у SUN грандиозные планы подвинуть другие никсы и виндуз на серваках в первую очередь и на десктопах - отсылаю к новостям о Яне Мердоке и проекте Indiana. Думаю не стоит расписывать кто он такой. Напомню - Debian.

http://www.nixp.ru/news/8378 >> Компания Sun Microsystems на конференции JavaOne представила свой новый проект — Indiana, цель которого — расширить присутствие операционной системы Solaris на рынках, занятых другой ОС с открытым кодом — GNU/Linux. << >> В общем, Sun хочет «сделать из Solaris лучший Linux, чем сам Linux», пояснил Мердок << >> По мнению Стивена Огрэйди (Stephen O'Grady), аналитика RedMonk, эта инициатива Sun — очень умный ход, поскольку поможет компании решить проблемы Solaris и упростить людям переход с Linux на Solaris. <<

http://getbits.info/opensolaris-zarabotaet-na-mejnfrejmax-ibm-9645 >> В Sun говорят, что на сегодня около четырех десятков крупных клиентов уже выразили заинтересованность в новой ОС и намерены ее использовать на оборудовании IBM. <<

Поэтому никакого двойного лицензирования не будет.