LINUX.ORG.RU

Линус Торвальдс высказался о ZFS

 , , ,


3

4

В процессе обсуждения планировщиков ядра Linux пользователь Джонатан Данти пожаловался, что изменения в ядре сломали важный сторонний модуль — ZFS. Вот что написал в ответ Торвальдс:

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

И, откровенно говоря, я не увижу ни одного шанса на включение ZFS в ядро, пока не получу официальное сообщение от Oracle, заверенное их главным юрисконсультом или, лучше всего, самим Ларри Эллисоном, в котором говорится, что всё ок, и ZFS теперь под GPL.

Некоторые думают, что добавить код ZFS к ядру — неплохая идея, и что интерфейс модуля нормально с этим справляется. Что ж, это их мнение. Я же не чувствую такое решение надёжным, учитывая спорную репутацию Oracle и проблемы, связанные с лицензированием.

Поэтому мне абсолютно неинтересны штуки вроде «слоёв совместимости ZFS», которые, как некоторые думают, изолируют Linux и ZFS друг от друга. Нам от этих слоёв никакой пользы, а учитывая склонность Oracle судиться из-за использования их интерфейсов — я не думаю, что это реально решает проблемы с лицензиями.

Не используйте ZFS. Вот и всё. По-моему, ZFS это больше баззворд, чем что-то ещё. Проблемы с лицензированием — только ещё одна причина, почему я никогда не стану заниматься этой ФС.

Все бенчмарки производительности ZFS, что я видел, совершенно не впечатляют. И, как я понимаю, ZFS уже даже толком не сопровождается, и никакой долгосрочной стабильностью здесь не пахнет. Зачем вообще её использовать?

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

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

Я помню. Более того, я даже знаю что они этим stable write получили. Правда конечно ценой жёсткой просадки производительности

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

Зачем писать то, что не имеет значения, в смысле, не может быть подсчитано, вычислено, выведено, проверено, если не чтобы потроллить?

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

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

Подсчитай количество фич ZFS для повышения надежности по сравнению с FAT и утрись.

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

ZFS и FAT

fat здесь использован как (контр)аргумент в пользу того, что ты пишешь то, что не имеет значения.

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

Замени слово FAT на аппаратный контроллер XXXYYYZZZ и получишь похожий расклад.

Так же сравни Шиндоуз на серверах и Linux.

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

Замени слово FAT на …

«и получишь похожий расклад» - то, что ты пишешь то, что «не имеет значения».

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

Единственная альтернатива, где есть что-то похожее на ZFS - это BTRFS, но увы, много отрицательных отзывов о надежности.

Хороший пример, BTRFS по архитектурным критериям похожа на ZFS, но из-за более низкой популярности менее оттестированна и отлажена.

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

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

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

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

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

использовать всю доступную оперативную память под долговременный файловый кэш

В век SSD это не нужно

alexferman ★★★ ()

Вот как-то же в винде не тащат с собой в ядре все возможные драйвера, а почти все драйвера являются как раз сторонними модулями. И как-то справляются.

вообще тащить все с собой в ядре кажется порочной практикой. Лучше стабильный апи для модулей.

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

ZFS не нуждается в услугах контроллера RAID и его батарейке. При обнаружении ошибок чтения и/или записи пулы ZFS приостанавливают свою работу до восстановления нормального состояния работы железа. Железо либо работает, либо не работает, а ZFS непрерывно контролирует это.

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

Вот поэтому я и отказался от ZFS

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

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

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

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

Какой ужасный модуль ядра! Его надо срочно в психушечку.

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

Вот кпримеру. Наглядно. Первый тест аля рукажоп, и второй с настроеным пулом прямыми руками https://www.percona.com/blog/2018/05/15/about-zfs-performance/

«Опустим обычную газету в серную кислоту, а журнал ТВ-Парк - в дистиллированную воду.»

Rootlexx ()
Последнее исправление: Rootlexx (всего исправлений: 1)
Ответ на: комментарий от crypt

L2arc это кеш на чтение, а не на запись. Вот у тебя hdd на 6ТБ к примеру и ты делаешь какой нибудь 256гб ssd быстрый в качестве L2arc. Вот у тебя 256 гб быстрого кеша. Вообще лучше про ARC почитай, неправильное представление у тебя о нем.

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

Конечно же Rootlexx на лоре лучше знает. Он тестов не проводил, но всё равно знает что percona пидорасы, а он дартаньян

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

Зачем писать то, что не имеет значения, в смысле, не может быть подсчитано, вычислено, выведено, проверено, если не чтобы потроллить?

Голосование по systemD в дебиан уже подсчитано, чтобы потролить Devuan :)))

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

Конечно же Rootlexx на лоре лучше знает. Он тестов не проводил, но всё равно знает что percona пидорасы, а он дартаньян

Rootlexx тестов не проводил - зато Rootlexx умеет читать. «В равных условиях ZFS медленнее - тогда давайте дадим ей L2ARC-кеш на NVMe SSD, а XFS никакого bcache не дадим - ух ты, ZFS стала быстрее, кто бы мог подумать!!1»

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

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

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

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

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

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

А кто виноват в том, что разрабы ZFS подумали и сделали 2 вида кеша, а XFS нет?

sky92 ()

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

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

А lvm разве так не умеет?

Помнится мне хотелось пощупать zfs из-за возможности делать снапшот автоматом при записи в фс (пресловутая cow). Думал это тема. И именно это не умеет (не умела на тот момент) lvm.

Но задача такая пропала. А если нет необходимости cow, то lvm вполне хватает. По крайне мере, lvm так ресурсы не жрёт.

А уж делать снапшоты по расписанию lvm умеет не хуже, чем zfs.

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

вот тебе в равных

Ага, проводится исключительно тест fsync(), и при этом используется ext4, известная своим медленным fsync() в некоторых ситуациях при опциях по умолчанию. При этом сами опции вообще не указаны. Сказочный тест.

Кроме того, в ядрах того времени, когда этот тест проводился, вроде ещё не было ext4_ilock/unlock-патча.

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

А кто виноват в том, что разрабы ZFS подумали и сделали 2 вида кеша, а XFS нет?

А кто помешал использовать bcache или lvmcache с XFS?

Rootlexx ()

Линус Торвальдс высказался о ZFS

Все таки он же «высказался», а не «выразился» /значит не все так плохо/.

PS: Кто берет комментарии в круглые скобки, тот - НЕ ПРОГРАММИСТ.

Владимир

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

Неспособность линуксовых ФС использовать всю доступную оперативную память под долговременный файловый кэш

Положи эту чушь там, где взял.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Разве VFS поверх любой FS кроме сложных типа ZFS не отдает всю свободную оперативку под файловый кэш автоматически? И потом очищает ее по мере запросов разных приложений.

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

Это откуда такое?

Из мира классических СХД.

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

Разве VFS поверх любой FS <…> не отдает всю свободную оперативку под файловый кэш автоматически?

Разумеется, это так.

кроме сложных типа ZFS

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от mv

1.56% для классического сектора в 520 байт (512 - данные, 8 - CRC). Если ты в шапочке из фольги сидишь, как нам тут втираешь, то это весьма немало, да?

Эта цифра строится на предположении, что в случае повреждения сектора он равновероятно принимает любое случайное значение. Но это не так.

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

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

Следуя этой логике, ни один продукт в мире не может стать надёжным, оттестированным и популярным, в том числе и ZFS. Тем не менее, они как-то становятся таковыми. Вывод: логика неверна.

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

PS: Кто берет комментарии в круглые скобки, тот - НЕ ПРОГРАММИСТ.

У того «отлично» по русскому.

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

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

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

Обычно тот, кто первый встал в некой отрасли - того и тапки.

Зайти на зрелый рынок достаточно сложно, особенно в наукоемкой отрасли, где на разработку конкурирующего варианта нужно много квалифицированных человеколет.

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

a_buchinskiy ()
Ответ на: комментарий от anonymous
  • Дорога ложка к обеду.

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

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

Можно либо первым придти, либо ждать пока с этим первым что то случиться (сдохнет или морально устареет).

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

Ну если уже про сторонние решения - тогда давай дойдём до редисов и мемкешей всяких, чтоб уж наверняка.

А требовался именно комбайн «всё в одном» без разделения на уровни абстракции? Ну, тогда XFS не подходит, да. :)

Требование для проведения тестирования очень простое: объекты сравнения должны быть в равной ситуации. А то, что ZFS может быть очень медленной с маленьким ARC и очень быстрой - с большим, и L2ARC на NVMe - всё это и так было известно.

Короче - обе версии имеют право жить и используются(это факт).

Да конечно используются! Каждый волен выбирать решение, которое больше нравится или больше подходит в конкретной ситуации. Больше вариантов - больше выбор. Так что пускай расцветают все цветы.

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

либо ждать пока с этим первым что то случиться (сдохнет или морально устареет).

У ZFS огромный задел наработок, начиная с 2001 года.

Файловая система очень надежная, отличная поддержка лаборатории Livermore, отличные специалисты - разработчики.

Большое количество историй успеха.

Очень смешно наблюдать тут индивидов, которые пишут в духе, а я вот скопировал на FAT 100 фильмов по одному гигу каждый и моя FAT уделала ваш ZFS в пух и прах.

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

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

Когда Linux-фанбой считает, что дно уже достигнуто и падать дальше некуда, ему снизу стучит BSD-кун.

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

Самый главный забияка - это Dimez и его спонсоры.

У тебя опять обострение, шиз?

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

а еще бывает третье состояние, когда ошибки видит только ZFS, собственно в этом-то и проблема аппаратных контроллеров.

Если raid-контроллер использовать как недо-hba, то он, естественно, не знает, что с диска пришёл некорректный бит. Это ж матчасть крайне начального уровня, однако ты и её не знаешь, а мнение имеешь.

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

А для чего тогда CRC в SMART?

И почему ZFS прекрасно видит ошибки на одиночных устройствах?

А еще ты путаешь HBA с однодисковым томом JBOD, о котором шла речь.

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

Нет, не путаю, ты просто не умеешь читать. Впрочем, как всегда.

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

Т.е. получается, JBOD не хранит даже контрольных сумм блоков как ZFS?

Действительно с RAID контроллерами у меня опыта очень мало и в основном неприятности с ними случались, почти сразу перешел потом на ZFS и HBA и стараюсь не связываться с шибко умными дисковыми контроллерами.

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

а кто в здравом уме крутит базы на файловых системах?

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

Можешь погуглить по словам Oracle db zfs vs raw disk. Там первой же ссылкой всё написано

Nastishka ★★★★ ()

Торвальдс

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

anonymous ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)