LINUX.ORG.RU

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

 , , ,


3

4

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

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

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

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

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

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

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

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

Deleted

Проверено: a1batross ()

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

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

Ну мне лень, превозмогая специально для тебя:

Using a write-back is dangerous and puts your data at risk. Out-of-order execution of I/O may also cause corruption in case of a reset/crash; some newer I/O requests did make it to disk while some older I/O requests did not.

To use a controller safely with ZFS it needs to support BIO_FLUSH; write-back likely ignores these requests. Basically you’re playing with fire. You also lose most of the ZFS benefits, such as Self Healing and protection against BER/corruption. For all intents and purposes; ZFS treats your array as being non-redundant.

I’d say ZFS is one good example of how Software RAID can be superior to Hardware RAID in a fundamental level.

https://forums.freebsd.org/threads/raid-controller-cache-and-zfs.13720/

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

И оказалось, что ошибка в корневой чексумме…

Удостоверяющий центр был непгавильный.

Всем спасибо, все свободны.

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

Удостоверяющий центр был непгавильный.

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

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

Центр такой же человек, как все остальные.

Центр - это Организация, а не человек!

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

Остальные - это Организация, а не человек!

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

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

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

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

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

Можешь привести много примеров более упорядоченных организаций, чем корневой УЦ РФ или УЦ GPG keyring-ов?

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

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

Не знаю.

Зачем мне себе противоречить? Все (человеческие) организации одинаково упорядочены, влюбчивы, продажны и смертны, как все остальные. А конкретные случаи - это воля случая.

anonymous ()
  • Форк мне запили!
  • Таблетки принял?
  • Форк мне запили!
  • таблетки принял?
  • Форк мне запили!
anonymous ()
Ответ на: комментарий от a_buchinskiy

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

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

не, пойми правильно, я оценил твое усилие погуглить, спасибо.

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

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

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

Try not to put any layer between ZFS and where data is really stored (RAM, Raid, NCQ, internal disk cache, etc)… as much as you can afford.

https://serverfault.com/questions/545252/zfs-best-practices-with-hardware-raid

The idea with ZFS is to let it known as much as possible how the disks are behaving. Then, from worst to better: Hardware raid (ZFS has absolutely no clue about the real hardware), JBOD mode (The issue being more about any potential expander: less bandwidth), HBA mode being the ideal (ZFS knows everything about the disks) As ZFS is quite paranoid about hardware, the less hiding there is, the more it can cope with any hardware issues. And as pointed out by Sammitch, RAID Controller configurations and ZFS may be very difficult to restore or reconfigure when it fails (i.e. hardware failure).

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

Так ты забываешь про метаданные (дерево хранения). Они всегда CoW, а потом ты атомарно перезаписываешь указатель на корень дерева в суперблоке.

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

А какой смысл в твоем аппаратном кэшировании, если ZFS пишет данные всегда последовательно ессно в пределах текущей фрагментации пула?

Закэшировать метаданные? А потом, чтобы накрылся весь пул? Последние версии ZFS позволяют вынести только метаданные целиком на другое устройство, например, на промышленные SSD.

Смысла в использовании кэша контроллера с ZFS нет от слова СОВСЕМ, если ты конечно не хочешь добавить дополнительную потенциальную точку сбоя.

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

так... и теперь это не аноним, а... еще один аноним.

запрет на использование ZFS поверх hardware raid - это городской миф, который самими разработчиками как раз не подтверждается.

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

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

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

Смысла в использовании кэша контроллера с ZFS нет от слова СОВСЕМ

ага, городить l2arc или как он там на SSD есть смысл, а использовать DDR память контроллера в качестве кеша нет смысла:)

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

Когда пул потеряешь, может быть, увидишь разницу.

ZFS пул поверх контроллера с RAID рекомендуют (если нет других вариантов без RAID) делать через однодисковые тома БЕЗ write cache.

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

Ну это было со слов одного из разработчиков в чатеге.

Зайди в чатег и спроси сам.

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

ну вот опять ты меня в гугл послал:((( есть такая штука best practice, особенно если технология в продакшене больше 10 лет. есть deployment guides. не надо в меня ссылками на чатики тыкать.

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

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

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

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

есть такая штука best practice, особенно если технология в продакшене больше 10 лет. есть deployment guides. не надо в меня ссылками на чатики тыкать.

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

ну вообще-то таблицы это и есть рандом.

Например oracle table extent size. Там владельцы ZFS

а кто в здравом уме крутит базы на файловых системах? не, я понимаю недобазы, но ты заикнулась про оракл. хотя и там всё нормально, я выше кидал ссылку где dm-cache и bcache с ext4 обосрались в 2 и 3 раза на mysql посравнению с zfs + slog.

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

ага, городить l2arc или как он там на SSD есть смысл, а использовать DDR память контроллера в качестве кеша нет смысла:)

У тебя фундаментальное непонимание принципов работы ZFS.

L2ARC - это read cache, его можно на ходу выдергивать и программы этого даже не заметят без учета просадки производительности.

Ты не понимаешь, как работает ZFS на запись, что такое Intent Log и почему нет смысла в кэшировании аппаратным козлом. Есть еще одна пословица про козла и огород, так вот для сохранности данных рекомендуют, козла (hardware raid cache) в огород не пускать.

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

есть такая штука best practice, особенно если технология в продакшене больше 10 лет. есть deployment guides. не надо в меня ссылками на чатики тыкать.

Иди в жопу. Надоел ты уже. У таких как ты только в пустом трепе best practice.

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

Хотя бы потому что SAS контроллер пропускал ошибки, которые видел ZFS, а вдруг у контроллера оперативка того? И таких вдруг можно напридумывать несколько, поэтому лучше всего использовать HBA и не заморачивать с аппаратными RAID железяками.

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

и тем не менее read cache в DDR быстрее. а все остальное - это блаблабла

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

Вряд ли. Ну вот не верю я, что даже хваленая ZFS перенесет без последствий для производительности хотя бы пару пару десятков тысяч снапшотов

вообще не проблема, в отличии от lvm.

Ну и самое главное, что ИТ движется в облака

всё ИТ туда всё-равно не уйдёт и самые жирные места всегда будут иметь большую часть своей инфраструктуры на месте.

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

поэтому лучше всего использовать HBA и не заморачивать с аппаратными RAID железяками.

аппаратные raid железяки работают в HBA режиме, так что с этим все ок.

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

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

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

и тем не менее read cache в DDR быстрее. а все остальное - это блаблабла

Расшифруй свое сообщение.

Intent Log на промышленном SSD зеркале медленее твоего DDR?

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

аппаратные raid железяки работают в HBA режиме, так что с этим все ок.

Обычно всего лишь в режиме виртуальных однодисковых томов JBOD, а не HBA pass-through - это во первых.

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

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

Когда у тебя превалирует случайный доступ, то как-то пофиг на фрагментацию. А случайный доступ - это примерно любой сервер, кроме всяких видеонаблюдений и ко.

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

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

Надоел ты уже.

Confirming, affirmative.

Иди в жопу.

Пусть лучше идет в RTFM читать FAQи - полезнее для общества :)

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

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

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

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

ZFS хотя бы промышленно применялась уже с момента выхода десяточки. Той что Solaris 10.

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

Естественно сам zfs, который работает в таком окружении, написан богами, и не может имеет ошибок.

Сравни популярность ZFSonLinux и какой-нибудь блобной прошивки контроллера SkyNet семикондастер.

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

И пойми, что non open source - абсолютно не конкурент для open source по критериям надежности при сравнимом уровне финансирования.

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

Еще цену сравни на ZFS и аппаратный контроллер. Получается что OpenIndiana/FreeBSD/Linux стоят как этот самый контроллер. А еще не забудь вспомнить сколько было миллионов часов работы в нагрузке у самых разных держателей ZFS.

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

Сравни популярность ZFS…

надежности

Если сравнивать твою «надежность» по «популярности», то, думаю, fat(exfat) должен быть вне конкуренции.

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

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

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

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

Попробуй написать свой вариант FAT и найди хотя бы пару тестеров для него, а потом сравни надежность Microsoft FAT и Васян FAT.

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

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

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

Ну ты же понимаешь, что у решения обычно есть … факторы

И, конечно же, у тебя есть однозначная функция, дающая значение надежности от этих факторов.

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

Конечно же и бюджет и интерес к этой области.

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

Причем когда очевидно из общих выкладок, не требуя детальных анализов материалов.

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

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

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

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