LINUX.ORG.RU

Вышел ZFS-FUSE 0.5.0

 ,


0

0

ZFS-FUSE позволяет читать и писать на тома с файловой системой ZFS. Реализация ZFS в ядре Linux невозможна из-за несовместимости GPL и CDDL, поэтому портирование ZFS на Linux происходит с помощью FUSE.

Лицензия: CDDL.

Изменения с версии 0.4.0:

  • Добавлена поддержка асинхронного ввода-вывода и сжатия gzip.
  • Портирование на Sparc64.
  • Исправлены ошибки сброса кэша ATA/SATA/SCSI-дисков и запуска на 32-битных системах.

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

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

> Расскажите, очень интересно. Я ни разу не видел упавшую UFS2.

iZEN, я уже говорил Вам, придётся повторить: Ваша убеждённость вызывает уважение, но сказок рассказывать не нужно. UFS2 кладётся до невосстановимого состояния несколькими последовательными выключениями во время активного использования дисков, или просто в момент fsck после предыдущего сбоя. Я до сих пор помню срач на bsdportal.ru, когда меня закидывали говном всем форумом за то, что я усомнился в надёжности UFS. А чуть позже на форуме какой-то персонаж робко пытался получить помощь после того, как потерял 200GB архив с музыкой. AFAIR, не получил.

Это касается также и нескольких других распространённых мифов для BSD-неофитов, которые Вы любите периодически цитировать. Не надо их мусолить; одни из них уже устарели, другие же были сильно притянуты за уши или просто лживы с самого начала. Пропаганда Pavlovsky-style всегда вредила этой, в общем-то отличной, системе.

P.S. Если что, я сам - вполне довольный пользователь FreeBSD.

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

>А я думаю, что разрабы FreeBSD прекрасно осведомлены о нише, занимаемой их поделием - десятилетней давности локалхосты красноглазых Васей Пупкиных, да роутеры в быдлоконторках, да гомнохостинги быдлосайтов на похапе.

Еще один дятел... Yahoo, к примеру, на FreeBSD крутится - это для тебя достаточно энтерпрайзно?

alex-w ★★★★★
()
Ответ на: комментарий от iZEN

>Вот только не надо приравнивать GNU к Open Source. Open Source гораздо обширнее, чем предполагают многие линуксойды.

+1

alex-w ★★★★★
()
Ответ на: комментарий от black7

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

да ну? ты правда думаешь, что OSS сводится к одному только GNU?

alex-w ★★★★★
()
Ответ на: комментарий от abbath

Запрещает использовать GPL, а не CDDL. Все претензии к FSF.

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

>Сударь, это не у Вас ли не собирались в Debian ровно половина пакетов из репозитория?

Нет, не у меня. Я не использую Debian.

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

> lvm если и найдет несовпадающую checksum'у, то фиг укажет какой файл стоит заменить при отсутствии репликаций.

lvm не отвечает за файлы. lvm отвечает за устройства, вообще-то...

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

> А я сказал, что в ФС эти функции не нужны.

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

Или вот хранение документации или исходников - задал сжатие каталога - и каталог занимает на диске в три раза меньше места.

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

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

>Нет, не у меня. Я не использую Debian.

Но Вы же с такой уверенностью об этом заявляли ( http://www.linux.org.ru/view-message.jsp?msgid=3011091#3011411 ) и я осмелился сделать вывод, что Вы давний пользователь Debian (ибо что бы протестить такое число пакетов нужно не мало времени (; )

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

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

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

>lvm если и найдет несовпадающую checksum'у, то фиг укажет какой файл стоит заменить при отсутствии репликаций

LVM вернет ошибку драйверу ФС, ФС ядру, ядро приложению. Результат как в zfs, только проще в реализации, а значит надежнее.

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

> LVM вернет ошибку драйверу ФС, ФС ядру, ядро приложению. Результат как в zfs, только проще в реализации, а значит надежнее.

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

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

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

cache ★★
()
Ответ на: комментарий от X-Pilot

>Firefox основан на MPL и есть почти в каждом дистрибутиве (кроме Debian)

4.2 man iceweasel

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

Когда признают ext4 стабильной, то будет в Linux более-менее нормальная fs
Пока только разработчики ext4 говорят, что ext4 стабильна :)

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

Я конечно, поддерживаю ZFS вообщем и в FreeBSD в частности,
но вот не надо так передергивать !

То что ext3 не умеет отложенную разметку делать - это как бы все знают.
На том же железе под UFS2 будет те же 30 мин форматироваться, а вот под XFS будет быстро форматироваться.

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

>>Сударь, это не у Вас ли не собирались в Debian ровно половина пакетов из репозитория?

>Нет, не у меня. Я не использую Debian.

У Вас, у Вас. Я ещё тогда тоже спорил и помню. Я правда не помню, что там было со второй половиной, но тоже что-то не очень хорошее...

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

Точно. Вот тут и ссылку привели...

"не тестировалось ни разу (хе-хе)"

И в том же треде Вы так и не ответили за свои слова. Можем продолжить в этом.

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

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

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

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

Стандартизация рулит, любой lvm подходит к любой fs, любая карта pci подходит к любому контроллеру pci...

Кроме того, разработчики и так в одной команде. Вход свободный, присылайте патчи.

>Пример с файлами, которые система разбрасывает по разным носителям, чтобы максимально обезопасить...

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

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

> FreeBSD же остаётся в своём 1998 году и по сей день.

вместе с ними там же рядом живет macosx , медленно и уверенно выкидывая win/lin с десктопов . где-то же рядом с freebsd живет netapp , странным образом продолжающий поддерживать проект . вот и некоторые "странные" вендоры до сих пор не могут соскочить с vxworks на наишикарнейший linux в виду такой весь примечательный и открытый , но в реальности имеющий существенные проблемы и с лицензированием в т ч . так что освоение будет своим ходом , возможно , в некотрых областях линакс будет заменен "поделиями" .

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

> LVM вернет ошибку драйверу ФС, ФС ядру, ядро приложению. Результат как в zfs, только проще в реализации, а значит надежнее.

а что не так в таком подходе ? соль и простота zfs не в этом ...

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

>Вот я после нескольких раз повторения одного и того же вопроса до сих пор жду ответа. И это мне пришлось несколько раз повторять простой вопрос! ж)

Антон? Уральский, ты?!

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

> это вашему копирастопиару - цена грошь. а подобных вам, неблагодарных, юзающих GNU/Linux

я не юзаю каку Linux, только GNU софт. Тролль тоньше.

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

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

Отличная фича. У меня на ноутбуке 1 (один) винт. Зеркала не организовать. Из-за специфики работы резервное копирование может выполняться и каждый день (норма), и раз в две недели. Каждый день в рабочем каталоге меняется куча файлов. И зная, что каждый файл лежит на диске в трёх копиях, я ощущаю себя несколько спокойней, поскольку покрытие бэдами от сильного удара какой-то области диска с гораздо меньшей вероятностью мне что-нибудь порушит. Понятно, что винт убить можно и насовсем - но, в любом случае, вероятность выцарапать данные гораздо выше.

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

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

Нет, не я.

А что, у вас тут всегда так - языком потрепали и на этом всё, дельного ничего никто не может сказать? Вот товарищ борисыч потрепался и заглох. Ноу-даши убеждает всех, что "это не нужно". Цирк какой-то

anonymous
()
Ответ на: 4.2 от anonymous

>Расскажите это ребятам из Apple, Juniper, Nokia, IronPort, NetApp, Isilon, Y!, и вообще, stop the FUD.

С Apple всё понятно - потырили из BSD код. Очень достойное применение BSD. Дальше.
Juniper, NetApp - прозреваю использование BSD как embedded OS. Был у меня опыт работы с NAS-сервером, прошивка которого была основана на BSD. Надо ли говорить, с каким боем пришлось выцарапывал данные с BSD-шного vinum'а, когда NAS почему-то ВНЕЗАПНО перестал загружаться.

О способах применения BSD в остальных конторах с удовольствием послушаю.

>Та же GPLv3 месяцами штудировалось лоерами ... допустима ли она для contributed софта

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

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

> Причём zfs будет стремиться раскидать блоки по разным устройствам

А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

> шансы откачать информацию в случае появления бэдов существенно увеличиваются

... при регулярном выполнении бэкапов, да.

no-dashi ★★★★★
()
Ответ на: комментарий от cache

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

Потому, что дублирующиеся сущности. Каждая из подстистем в отдельности дааавно уже вылизана, и баги лезут только в весьма экстравагантных случаях. А в ZFS был повторно изобретен велосипед, путем дублирующей реализации всего, что уже сделано в LVM, blkdev, VFS и собственно драйверах файловых систем.

> единой командой должна наоборот, дать лучший результат.

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

Пример с "хранением данных в нескольки копиях" мы уже рассмотрели, прозрачно сжатие? Ну НЕ НУЖНО оно. Нынче бытовой накопитель имеет объем 500 гигабайт и стоит $100. Даже не смешно.

no-dashi ★★★★★
()
Ответ на: комментарий от cache

> Отличная фича. У меня на ноутбуке 1 (один) винт. Зеркала не организовать

Есть LVM, есть разделы, есть rsync. Они уже работают, и они дадут ЗАМЕТНО БОЛЬШУЮ надежность.

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

> А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

уже тысячу раз говорили, zfs не отменяет необходимости backup'а. checksum'ы и копии помогают от незаметных глюках железа

а метаданные могут пропасть глюкануть и у logical volume manager'а; знаем, проходили

> ... при регулярном выполнении бэкапов, да.

регулярный бекап не спасет от того, что ты можешь прозевать как в бекапе окажутся битые данные из-за того, что контроллер чуть-чуть пошалил. checksum'ы и резервные копии дают шанс найти (и исправить).

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

> есть rsync

ога, очень эффективно на больших объемах :rofl:

> Они уже работают, и они дадут ЗАМЕТНО БОЛЬШУЮ надежность.

zfs тоже *уже* работает и *уже* дает заметно большую надежность на сановских серверах и начинает награждать фряшников и (скоро?) нетников

btw, до zfs во фре использовали geom, что есть более гибкий аналог линуксявого lvm, а до geom был vinum, ccd и куча костылей...

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

> Потому, что дублирующиеся сущности. Каждая из подстистем в отдельности дааавно уже вылизана, и баги лезут только в весьма экстравагантных случаях. А в ZFS был повторно изобретен велосипед, путем дублирующей реализации всего, что уже сделано в LVM, blkdev, VFS и собственно драйверах файловых систем.

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

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

> В настоящий момент живущие в линуксовом ядре "стабильные" ФС дают производительность, сравнимую со скоростью работы физического накопителя

Ложь.

> для 99.99% случаев их эффективность достаточна

Отучаемся говорить за всех.

> А "фичи"... Ну да, звучит все это как минимум интересно. Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

Расскажите, как реализовать все (подчёркиваю: ВСЕ) возможности ZFS в Линуксе. С тестами, доказывающими сравнимый уровень производительности и надёжности. С примерами использования в существующих датацентрах и системай уровня предприятия.

>сжатие? Ну НЕ НУЖНО оно. Нынче бытовой накопитель имеет объем 500 гигабайт и стоит $100. Даже не смешно.

Зелен виноград.

anonymous
()

Унылый флейм.

zfs никому кроме сановской соляры и нищих БСДшников не нужен.
На соляре просто не было адекватной системы управления томами (svm слабое подобие левой руки)

Всe.
Mелкому бизнесу нет нужды в zfs, так как нет терабайтов инфы.
Среднему бизнесу ??? а будет ли там сановское железо?
Крупный бизнес сидит на стораджах типа EMC и zfs идет лесом.

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

> checksum'ы и резервные копии дают шанс найти (и исправить).

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

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

> А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

Ну, вроде как и это разработчики учли. :) Метаданные резервируются тоже. Причём, и тут интеграция системы играет положительную роль - фс, зная об устройстве физического уровня, резервирует метаданные оптимально по скорости и надёжности.

> Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

Голословное утверждение. Перестанет быть таковым, если Вы приведёте пример того, как организовать наиболее вкусные особенности zfs средствами lvm/ext3/etc.

> Пример с "хранением данных в нескольки копиях" мы уже рассмотрели, прозрачно сжатие? Ну НЕ НУЖНО оно. Нынче бытовой накопитель имеет объем 500 гигабайт и стоит $100. Даже не смешно.

Ну... У меня исходники занимают около 25ГБ, и разного рода документация - около 50. Винт на ноуте - 250. На данный момент сжатие для исходников - 3.26, для документов - 1.89. Экономия навскидку около 40ГБ. А мне ещё, каюсь - грешен, хочется на винте коллекцию музыки держать, фильмов несколько для минут досуга. Для работы - десяток распакованных виртуалок с имиджами дисков в 2-16ГБ, и ещё десяток запакованных... Так что экономия 16% винта для меня весьма существенна.

А вообще - безапелляционность утверждений до добра не доводит. Не надо говорить за весь мир.

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

> zfs никому кроме сановской соляры и нищих БСДшников не нужен.

Как же я сразу-то не понял... Спасибо, просветил.

> Mелкому бизнесу нет нужды в zfs, так как нет терабайтов инфы.

Сейчас терабайты инфы встречаются даже у домашних пользователей. У что до мелкого бизнеса - у меня в офисе на 30 компов - 9ТБ хранилище. Заполнено уже на 40%. Планируем расширяться.

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

>У что до мелкого бизнеса - у меня в офисе на 30 компов - 9ТБ хранилище. Заполнено уже на 40%. Планируем расширяться

порнуха? музыка? фильмы?

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

> порнуха? музыка? фильмы?

Проектная документация. Но - Вам не всё ли равно? Пример приведён. Так что не нужно безапелляционных заявлений.

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

> >Проектная документация

> Терабайты? Не верю.

Это элементарно! Кладём большие и жирные бинарники в какую-нить систему контроля версий почаще. Вуаля! А когда этим будут заниматься куча пользователей... Мммм...

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

> Это элементарно! Кладём большие и жирные бинарники в какую-нить систему контроля версий почаще. Вуаля! А когда этим будут заниматься куча пользователей... Мммм...

Почти так. Средний размер типичного проекта за весь цикл проектирования составляет около 50ГБ. Это всё - исходные данные, версии, сопутствующие материалы от заказчиков, и т.д. Сюда добавляются копии проектных рабочих каталогов пользователей по закрытию проекта - ещё 20-30ГБ. В результате на разделе занято уже около 3.5ТБ из 8, и чем дальше, тем быстрее хранилище заполняется.

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

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

Не только бздуны. Но и Apple тогда бы пришлось искать компилятор для компиляции исходников своей очередной версии Mac OS X. :)
(У Apple давно 7% рынка настольных ПК.)

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

> А что собой представляет хранилище?

А какая разница? Речь шла о возможности таких объемов? Так вот они, объемы-то.

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

>> Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

> Голословное утверждение. Перестанет быть таковым, если Вы приведёте пример того, как организовать наиболее вкусные особенности zfs средствами lvm/ext3/etc.


Что ты считаешь вкусными средствами zfs? Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)? Снапшоты, которые без транзакционности (см. пункт 1) ничем не лучше обычного tar?

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

> Что ты считаешь вкусными средствами zfs? Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)? Снапшоты, которые без транзакционности (см. пункт 1) ничем не лучше обычного tar?

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

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

Re^2: Вышел ZFS-FUSE 0.5.0

>> Что ты считаешь вкусными средствами zfs? Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)? Снапшоты, которые без транзакционности (см. пункт 1) ничем не лучше обычного tar?

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


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

gaa ★★
()
Ответ на: Re^2: Вышел ZFS-FUSE 0.5.0 от gaa

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

Уточните, какие программы надо переписывать.

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