После десяти месяцев разработки увидел свет (http://permalink.gmane.org/gmane.linux.file-systems.zfs.anno...) релиз ZFSonLinux 0.6.3 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Реализованная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава Illumos и FreeBSD. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.В рамках ZFSonLinux подготовлена стабильная и полнофункциональная реализация поддержки компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre.
Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo, Sabayon Linux и AltLinux. Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.
Основные изменения:
- Совместимость со свежими выпусками ядра Linux, вплоть до 3.14;
- Более плавное регулирование интенсивности операций записи для достижения устойчивой производительности под нагрузкой;
- Повышена эффективность кэширования, что позволило добиться увеличения числа попаданий в кэш для некоторых видов нагрузки;
- Поддержка ACL в стиле POSIX;
- Поддержка атрибутов файлов "неизменяемый" и "только для добавления";
- Поддержка монтирования файловых систем с обновлениями типа relatime (время доступа обновляется только если оно раньше, чем время модификации);
- Интеграция с SELinux;
- Поддержка Systemd и улучшенная интеграция с дистрибутивами на его основе;
- Новый демон ZED (ZFS Event Daemon) для мониторинга и управления пулом;
- Поддержка архитектур aarch64 и sparc64;
- Многочисленные оптимизации производительности;
- Устранено более 200 ошибок.
URL: http://permalink.gmane.org/gmane.linux.file-systems.zfs.anno...
Новость: http://www.opennet.me/opennews/art.shtml?num=40000
TRIM всё ещё не поддерживается?
Насколько я помню, именно эти ребята TRIM для ZFS и реализовали, порядка года назад. А потом уже у них бсдшники скопипастили. И вообще теперь, походу, вся разработка открытой версии ZFS на них держится.
правильная версия того, где вся разработка открытой версии ZFS: http://open-zfs.org/wiki/Main_Page
Речь шла не о том, где разработка, а о том, кто разрабатывает.
> правильная версия того, где вся разработка открытой версии ZFS: http://open-zfs.org/wiki/Main_PageВы-бы хоть по своим линкам сами ходили и читали, что там написано ... Это коммьюнити общий для ZFSonLinux, ZFS on Mac OS X, и ZFS для Illumos и FreeBSD. Всё ... Основная разработка сейчас идёт именно сообществом ZFSonLinux. Illumos тоже работает, они добавили сжатие lz4 к примеру.
Добавили бы LZO1X было бы лучше :)
LZ4 сжимает хуже и на HDD дает результат хуже, ежели LZO1X.
> Добавили бы LZO1X было бы лучше :)
> LZ4 сжимает хуже и на HDD дает результат хуже, ежели LZO1X.Если и хуже, то не более 1-2%. Но у LZ4 есть LZ4HC (значительно лучше сжатие при той же скорости разжатия), так что использование LZ4 более универсально, даёт больше "пространства для манёвра".
> Добавили бы LZO1X было бы лучше :)Да примерно однофигственно - они вполне сравнимы по степени сжатия и скорости и конкретика зависит от входных данных.
http://open-zfs.org/wiki/Features#TRIM_Support
То-то я смотрю в zfsonlinux пока не видно multi_vdev_crash_dump, spacemap_histogram, enabled_txg, hole_birth, extensible_dataset, bookmarks и пр., что давно уже работает во фряхе. Так, что где идёт разработка ещё очень большой вопрос.
Ну не скажите. Линуксоиды же запилили совместимость с systemd, а это ГЛАВНОЕ Ж)
Зря ржёшь. Linux == systemd, RH7/CO/Debian/Suse/FC/MandaРаком*/Arch - все там.
Только 2-е осталось: гента, но она давно сползла в УГ и не нужна, да слака. Я ея 100500 лет не то что не юзал но даже не видел - так что не скажу.
Так чтааа ... таки да - ГЛАВНОЕ Ж)
> Только 2-е осталось:Нифигасе подсчет. Если вы других дистров не знаете - это не значит что их нет.
а в ВОВ победил кто, немцы?
найти сам сможешь, если озадачишься, кто реализовал поддержку trim.
почему её нет в бубунтурепозитории?
Уже больше года стоит ZFS на Ubuntu на NAS сервере организации. Очень нравится!
> Поддержка ACL в стиле POSIX;бесполезно изначально, в любой ФС.
> Поддержка Systemd и улучшенная интеграция с дистрибутивами на его основе;
O_o в драйвере ФС?
> бесполезно изначально, в любой ФС.А я встречал тех кому нравится.
> O_o в драйвере ФС?
Наверное, расово верный запуск ZEDа.
>> O_o в драйвере ФС?
>Наверное, расово верный запуск ZEDа.А на самом деле поддержка загрузки с / на ZFS
>> Поддержка ACL в стиле POSIX;
>бесполезно изначально, в любой ФС.Я пользуюсь. Удобно, знаете ли, отдельно взятому юзверю давать дополнительные права.
Мдя, качество коммьюнити определяется его составом. Опеннет опустился ... какие-то малограмотные дети всякую фигню пишут. Думали-бы, прежде чем что-то писать. ZFS объективно лучшая ФС за последние 10 лет. Использую её с 2007-го года (sparc/Solaris), под линуксом в продуктиве с прошлого года (ZFS on root). Очень радуют стабильность, производительность ZFSonLinux. brtfs настолько сырая и кривая, что польоваться ею, - бред. Снэпшоты lvm в подмётки не годятся zfs-ным.
> brtfs настолько сырая и кривая, что польоваться ею, - бредОбоснуй.
>> brtfs настолько сырая и кривая, что польоваться ею, - бред
> Обоснуй.Дисковый формат они стабилизировали. Это да факт. Однако:
https://btrfs.wiki.kernel.org/index.php/Main_Page
The Btrfs code base is under heavy development. Every effort is being made to keep it stable and fast. Due to the fast development speed, the state of development of the filesystem improves noticeably with every new Linux version, so it's recommended to run the most modern kernel possible.
Нужны самые современные ядра, они очень много и быстро разрабатывают. Будем говорить о качестве ? В каждом новом ядре исправления. Так вот в "ынтырпрайзе" новых ядер просто нет. Есть стабильные. И спрашивается, я что постоянно должен заниматься гемороем под названием brtfs, что-бы система стабильно работала и данные не пропадали ? brtfs стали продвигать в продуктоив года полтора-два как, и сразу куча проблем вылезла, - включая потери данных. Просто на список багов посмотрите.
Вот свежачок кстати:
60666 File Sys btrfs josef NEW --- 3.10.3 kernel BUG at fs/btrfs/ctree.c:3000 2014-05-25
62371 File Sys btrfs josef NEW --- 3.11.1 brtfs crash under memory pressure 2013-09-30
72151 File Sys btrfs josef NEW --- 3.13 Btrfs is corrupted and "brtfs check" craches during recovery 2014-03-15
3 bugs found.
> Так вот в "ынтырпрайзе" новых ядер просто нет. Есть стабильные.Прохладная былина, чувачок. Особенно если вспомнить про бэкпорты.
>> Так вот в "ынтырпрайзе" новых ядер просто нет. Есть стабильные.
> Прохладная былина, чувачок. Особенно если вспомнить про бэкпорты.В бэкпорты никто новый функционал не добавляет. А если и добавляет, то он урод которого расстреливать нужно. В стабильных ветках ядра должны быть фиксы багов и безопасности, нового функционала быть не должно. диверсантов типа Поцтеринга, нужно расстреливать.
> Поцтеринга, нужно расстреливать.Загвоздка в том что гарри поттер провернул немного своей уличной магии и расстреливать в результате будут другие, кулсисопов типа тебя, не способных к освоению изделий гарри поттера. Its magic, чувак.
> Вот свежачок кстати:
> 3.11.1 brtfs crash under memory pressure 2013-09-30Свежак, и правда. Еще и года не прошло. Да чтоб ты продукты в магазине так покупал.
> 3 bugs found.
Если это все что вы нашли - btrfs в намного более хорошем состоянии чем предполагалось. Но да, его лучше использовать с свежими ядрами/утилитами, некромансия не пройдет. И RAID5/6 пока сырые нафигЪ. А это ...для симметрии посмотреть на остальные ФС - не, не надо? А то там тоже много интересного можно в коммитах, багтрекерах и списках рассылки найти. Ну разве что кроме случаев неуловимого Джо и совсем примитивных дизайнов типа FAT.
Как за долбало бить пионэров по башке на работе, вроде вас.
> Как за долбало бить пионэров по башке на работе, вроде вас.Какое компетентное и технически аргументированное мнение. "Я еще только пять минут как из-за парты, но как же я вас, нубье, уже ненавижу!!!111".
>[оверквотинг удален]
> Свежак, и правда. Еще и года не прошло. Да чтоб ты продукты
> в магазине так покупал.
>> 3 bugs found.
> Если это все что вы нашли - btrfs в намного более хорошем
> состоянии чем предполагалось. Но да, его лучше использовать с свежими ядрами/утилитами,
> некромансия не пройдет. И RAID5/6 пока сырые нафигЪ. А это ...для
> симметрии посмотреть на остальные ФС - не, не надо? А то
> там тоже много интересного можно в коммитах, багтрекерах и списках рассылки
> найти. Ну разве что кроме случаев неуловимого Джо и совсем примитивных
> дизайнов типа FAT.А красавчег. Из 3-х багов 2 этого года. И все не закрытые. И это гуано в продуктив ? На домашний комп себе поставь.
В ZFS RAID-5/6 (Z/Z2) и даже с тройной чётностью работают без проблем уже много лет ... Почему я должен использовать brtfs ?
Из религиозных побуждений ? В жопу религиозных фанатиков !
> А красавчег. Из 3-х багов 2 этого года.Как специалист по качеству кода могу заметить что 3 бага за год в проекте такого масштаба - это очень хороший результат. А так я и предлагаю: что если посмотреть на другие ФС и вообще развиваемый код? Там тоже баги будут ведь. А куда они денутся? Чудес не бывает - проект такого масштаба неизбежно содержит баги.
> И все не закрытые.
Баги случившиеся "1 раз на всю планету" довольно сложно закрывать. Underlying причина, например создание структур с ошибкой - может быть починена год назад, но про это скорее всего никто не сможет вспомнить в рамках нового бага. А то что оно еще год работало, а потом все-таки упало - ну да, бывает и вот так.
> И это гуано в продуктив ? На домашний комп себе поставь.
А у меня есть пара томов с btrfs, приколись? И оно даже работает, если извращениями не заниматься. Правда, у меня везже весьма свежие ядра. Потому что я в отличие от - читаю каменты к коммитам и поэтому догадываюсь зачем ядра апдейтить :).
> В ZFS RAID-5/6 (Z/Z2) и даже с тройной чётностью работают без
> проблем уже много лет ...Понятие о "без проблем" у всех разное. Кого-то может и устроит тормозливый дизайн без экстентов, ручное управление кэшом и невозможность отобрать память гарантированно, клещинг с БД, сложности с изъятием дисков из пула и прочие прелести. А как по мне - в 2014 можно и получше CoW отбабахать, без таких проблем. И так, на уровне дизайна btrfs может например разложить вот этот файл как mirror, а вон тот - как stripe. А для вон того файла можно CoW отключить. С вон того диска можно без особых сложностей и быстро данные подвинуть на соседние и в результате корректно изъять диск из пула. С сокращением свободного места, ага. И гибкость в размещении структур такова что оно даже ранее лежавший ext4 может оформить как "а это у нас тут начальный снапшот, типа". И так далее. ИМХО очень перспективные задатки. И их нельзя просто пойти и привинтить сбоку, такие вещи требуют продумывания на фазе начального дизайна. В btrfs вот продумали, в отличие от.
> Почему я должен использовать brtfs ?
Никому вы ничего не должны, если не занимали.
> Из религиозных побуждений ? В жoпу религиозных фанатиков !
Вот я и говорю - саночные кулсисопы могут отправляться в жoпу со своим полурелигиозным маркетинговым булшитом типа рассказов о том как CoW не надо дефрагер. Ибо любой у кого мозг покрупнее куриного и кто понимает как работает CoW понимает что там фрагмент на фрагменте и фрагментом погоняет. А рассказывать про ненyжность дефрага могут только лицемеры и фанаты.
вопрос - зачем там экстенты - если там переменный размер блока?
По сути это тот же экстент - только называется иначе, и наш профайлинг говорит что с него реально добиться скоростей 2-4 GB/s на чтении, и порядка 2GB/s на запись. Приколись.
Чуть хуже ext4 + raid6, но бонусы архитектуры перекрывают минусы.А сколько дает ваша btrs ?
> вопрос - зачем там экстенты - если там переменный размер блока?Затем, что экстент позволяет помечать одним махом БОЛЬШОЙ регион. Это снижает оверхед по метаданным в ряде нагрузок. И в большинстве нагрузок это работает лучше. Поэтому большинство новых дизайнов взяли на вооружение эту технику. Правда просто? :)
> По сути это тот же экстент - только называется иначе,
Только максимальный размер сильно ниже. Стало быть оверхед на работу с метаданными - больше. Получилось истинно в духе санок: ни два, ни полтора. То-есть, дизайн уже усложнился, а вот хороших параметров из этого недоразумения никто так и не увидит. Вот и приходится подпирать гигазами буферов. Ну а хренли, рамдиски - они быстрые. Только это не заслуга структур разложенных на диске, мягко говоря.
> и наш профайлинг говорит что с него реально добиться скоростей 2-4 GB/s на
> чтении, и порядка 2GB/s на запись. Приколись.А приколись, "в среднем по больнице" экстенты будут при прочих равных в одной и той же конфиге эффективнее подобных недомерков под большинством нагрузок. Хуже от них как правило не становится, за исключением всяких клинических случаев "Шишкин-стайл" (когда некто поставил себе задачу нагнуть механику конкретной ФС).
> Чуть хуже ext4 + raid6,
А чуть - это сколько в граммах? И, конечно же, это было тестировано на свежем и пустом пуле, с нулевым временем эксплуатации, правда же? Ну так, чтобы не сталкиваться с всякой там фрагментацией от CoW и тем фактом что "дефрагера нету, б...ь!". Красиво втирать очки утырки из сана умеют, факт. А вот на неудобные вопросы - увиливают от ответа. А вот это мне уже не нравится, т.к. в результате "под капотом" обнаруживаются далеко не самые приятные сюрпризы, а снимая маркетинговую лапшу с ушей как-то лоховато себя ощущаешь.
> но бонусы архитектуры перекрывают минусы.
И какие там "бонусы архитектуры"? Я в основном увидел массу саночного маркетингового булшита. Но это плохой, негодный бонус. А так - первый блин комом. Ну вот и первый CoW-based дизайн который стал сколь-нибудь массовый - как-то так же.
> А сколько дает ваша btrs ?
Да без понятия - вы даже конфиг не указали, не говоря о том что шансы что у меня "совершенно случайно" окажется "рояль в кустах" в виде точно такого же конфига - достаточно скромные. Тем не менее, помнится btrfs вставлял ZFSу в бенчах даже когда был молодой и зеленый. А с тех пор его оптимизили к тому же. И еще вагон места для оптимизаций остался.
> Затем, что экстент позволяет помечать одним махом БОЛЬШОЙ регион. Это снижает оверхед по метаданным в ряде нагрузок. И в большинстве нагрузок это работает лучше. Поэтому большинство новых дизайнов взяли на вооружение эту технику. Правда просто? :)А теперь сравните с переменным размером блока. Блок может быть как 512 байт, а следующий блок может быть 2 мегабайта - что позволяет одном логическим блоком накрыть произвольный регион в файле. И чем это отличается от extent? ведь правда просто.
> Затем, что экстент позволяет помечать одним махом БОЛЬШОЙ регион. Это снижает оверхед по метаданным в ряде нагрузок. И в большинстве нагрузок это работает лучше. Поэтому большинство новых дизайнов взяли на вооружение эту технику. Правда просто? :)
Большой это сколько? в zfs размер блока может быть несколько мегабайтов. в ext4 extent примерно того же размера (просто организация fs такая что не выделишь неделимый кусок больше чем группа позволит).
Поймите же наконец - extent не панацея - ту же функциональность можно реализовать другими средствами.
что в zfs и сделали. Зато COW в случае блочной организации делается проще. Правда просто?> А приколись, "в среднем по больнице" экстенты будут при прочих равных в одной и той же конфиге эффективнее подобных недомерков под большинством нагрузок. Хуже от них как правило не становится, за исключением всяких клинических случаев "Шишкин-стайл" (когда некто поставил себе задачу нагнуть механику конкретной ФС).
Перестань курить траву и начинай думать. От того что переменный размер блока назвали extent - разницы не получается. Поверь у меня данных о том как ведут себя разные FS под большой нагрузкой - на порядок больше.
Большой - это реально большой - а не домашний NAS.
Не веришь - спроси Шигорина :) он таки догадывается из какой я конторы и чем занимаюсь.> но бонусы архитектуры перекрывают минусы.
> И какие там "бонусы архитектуры"Возможность без проблем выделить zvol в отдельный модуль и не иметь всякого POSIX overhead поверх тривиального контейнера с транзакциями. Хотя бы этот.
Ленивые транзации - сильно ленивые - что позволяют сильно агрегировать блоки в случае поточной записи. cache - что позволяет обходиться без подпорок типа flashcache/bcache и тому подобных, перемещая нужные данные на ssd для быстрого доступа.
raid-z сильно интересен, ибо близок к parity declustered raid, а не подпорки типа raid5/6.
чем это лучше - почитай в интернетах.Мало?
> Чуть хуже ext4 + raid6,
> А чуть - это сколько в граммах?около 10% если я правильно помню документ. А за ним лесть лениво.
> Да без понятия - вы даже конфиг не указали, не говоря о том что шансы что у меня "совершенно случайно" окажется "рояль в кустах" в виде точно такого же конфига - достаточно скромные. Тем не менее, помнится btrfs вставлял ZFSу в бенчах даже когда был молодой и зеленый. А с тех пор его оптимизили к тому же. И еще вагон места для оптимизаций остался.
Дисковая полка от CS9000. 5U84 в 2х raid-z. SAS, PCIe v3, LSI чип. Винты какие-то WD.
тюнинг не помню. Да и не я делал. Я лишь видел документы.
> А теперь сравните с переменным размером блока. Блок может быть как 512
> байт, а следующий блок может быть 2 мегабайта -А в EXT4 например экстент может быть 128Мб за 1 присест. Некая разница с 2Мб, да?
> что позволяет одном логическим блоком накрыть произвольный регион в файле.
Не "произвольный" а "до 2 мегабайтов". Спору нет, это лучше чем пипеткой по 512 байтов и даже 4Кб. Но смотрится полумерами на фоне нормальных экстентов.
> И чем это отличается от extent? ведь правда просто.
Размером. Ну и количеством операций с метаданными в результате. Потому и будет сдристывать в бенчмарках и дальше.
> Большой это сколько?
У EXT4 например до 128Мб. В btrfs честно говоря с ходу не помню какие лимиты, но весь пойнт экстентов - в том чтобы за 1 присест метить *большие* регионы. Чем больше - тем лучше. В плане оверхеда по метаданным. Потому что хранить размер экстента где-то и как-то все это адресовать - придется, а если экстентов много и мелких - это будет не сильно лучше более дубовых техник. А в клиническом случае (много мелких экстентов) - может оказаться даже хуже. Т.к. оверхед на работу с метаданными будет конский.
Эталонный пример покладания экстентной механики - скачать мелкоблочный и многогигабайтный торрент без преаллокации. Получится туева хуча экстентов и вы узнаете как выглядит оверхед при работе с метаданными.
> в ext4 extent примерно того же размера
Да, всего 128Мб. Вместо 2. В какие-то 64 раза отличие. Всего-то :).
> (просто организация fs такая что не выделишь неделимый кусок больше
> чем группа позволит).Ну да. Поэтому есть лимиты. Но 128Мб - это все-таки не 2. Это уже приличный кусок. В то что почти все записи умещаются в 128Мб - я еще поверю. В то что все записи лезут в 2Мб - да ЩАЗЗЗ.
> Поймите же наконец - extent не панацея - ту же функциональность можно
> реализовать другими средствами.Экстенты не панацея а средство снижения оверхеда по метаданным при файловых операциях и ускорения этих операций. И нет, блок в 2Мб не аналог экстента в 128Мб а дешевый китайский пластиковый эрзац в лучшем случае. Потому что в 64 раза меньше. Значит на одну запись 128Мб оно дернется 64 раза. А ext4 - один раз. "Небольшая" такая разница по оверхеду.
> что в zfs и сделали.
Там сделали как обычно в духе саней: оверинженеринг с хреновыми параметрами на выходе и громким маркетинговым булшитом вытягивающим инженерные ляпы.
> Зато COW в случае блочной организации делается проще.
Не очень понятно чем стало так уж сильно проще. Блоки переменного размера как верно замечено не очень отличаются от экстентов в плане того что кластерфак с вычислением размещения и хранением подобных сведений - уже появляется. И величина вида "100 блоков" уже не является чем-то определенным, так что многие возможные упрощения вычислений отваливаются. А вот эффективность характерная для экстентов - она где?! Сделать в 64 раза больше операций чем EXT4 на записи 128Мб куска - это не "эффективность". Это фэйл. У экстентных дизайнов сроду нет таких мизерных лимитов на размер.
> Правда просто?
Да, у саней так вообще любят - забить на сложные проблемы, получить нечто заурядное, а потом силами маркетоидов вытягивать это инженерное решение, выпячивая сильные стороны и запинав под ковер недостатки. Которые, однако, никуда не деваются. Просто потом будут неприятные сюрпризы о которых маркетоиды рассказать забудут. А я не люблю неприятные сюрпризы и предпочитаю честное понимание свойств. Какой мне смысл самого себя обманывать? Ну маркетологам то понятно какой - они продажи соляры толкали. А вот идея надувать самого себя мне кажется довольно спорной.
>> А приколись, "в среднем по больнице" экстенты будут при прочих равных в одной и той же конфиге эффективнее подобных недомерков под большинством нагрузок. Хуже от них как правило не становится, за исключением всяких клинических случаев "Шишкин-стайл" (когда некто поставил себе задачу нагнуть механику конкретной ФС).
> Перестань курить траву и начинай думать. От того что переменный размер блока
> назвали extent - разницы не получается.А разница в максимальном размере. Два мега - жалкая пародия на экстенты. В плане overhead по метаданным и числу операций.
> том как ведут себя разные FS под большой нагрузкой - на
> порядок больше.Никак не отменяет здравый смысл. И результаты бенчей с ним почему-то согласуются.
> Большой - это реально большой - а не домашний NAS.
А большая нагрузка - это работа со скоростями близкими к скорости линейного доступа накопителя. Если в терминах ФС. Работа с 100500 дисков в рамках одной ФС - это вообще отдельный случай, у вас оно кажется уже начинает становиться из разряда клиники. Если у вас задача вида "160Tb одним куском" - есть нехилый шанс что гнать надо архитекта такой системы, ссаными тряпками и сpaной метлой. А не геройствовать, фикся bottleneck-и в 1 системе, по принципу "ничего не знаю, после оптимизации даже кит и слон у нас полетят". Кэп намекает что 10 серверов с 16Тб дисков каждый имеют все основания работать лучше чем 1 сервак с 160Гб переросточным диском. Меньше мест для bottleneck-ов.
> Не веришь - спроси Шигорина :) он таки догадывается из какой я
> конторы и чем занимаюсь.По моим наблюдениям ты занимаешься болтологией, поливанием линя помоями и выгораживанием задницы саней и их технологий. При том я упорно не вижу ничего такого замечательного в этих сановских технологиях. В лучшем случае нечто достаточно заурядное и средненькое оказывается. А маркетинговых соплей зато - как для панацеи прямо.
> Возможность без проблем выделить zvol в отдельный модуль и не иметь всякого
> POSIX overhead поверх тривиального контейнера с транзакциями.Это очень нишевой "плюс архитектуры", нужный немногим. Обычно всем нужна прежде всего файловая система все-таки. И вот как файловая система ZFS выглядит переростком с довольно заурядными параметрами и рядом бестолковых ляпов.
> Хотя бы этот.
Не вижу чего ради оно должно считаться жирным плюсом "само по себе". Не, ну я понимаю что соляра - как вигвам, ничего нет. Поэтому в ZFS сани впихнули вообще все чего не хватало в соляре. Но в других осях и до ZFS уже был и менеджмент томов и управление кэшом. И поэтому за плюс впихон всего этого в ФС может считаться только с большими оговорками. Лишь когда дает что-то особенное, чего иначе не получается или получается плохо. В btrfs например RAID как минимум чисто техничечки может то, чего не может RAID блочного уровня: рулить уровнями RAID пообъектно. Ну ок, это мне понятно - достаточно интересный маневр, основанный на том факте что ФС сама рулит томами, знает на каких девайсах и сколько места и решает куда и сколько раскидать. И в нужный момент может принять решение "а как раскидывать по девайсам, собственно". Раскидав так как попросил юзер, если конечно это технически возможно (aka достаточно места на разных девайсах для реализации запрошенного варианта хранения). В этом случае мне такая архитектура еще понятна. А "сферический ZVOL в вакууме" конечно замечательно, но чего такого уникального и кому оно дает? Или может быть от того факта что "это ZVOL" что-то станет работать в 2 раза лучше чем было?
> Ленивые транзации - сильно ленивые - что позволяют сильно агрегировать блоки в
> случае поточной записи.С хрена ли оно плюс, если так или иначе объединять блоки умеют все современные ФС?
> cache - что позволяет обходиться без подпорок типа flashcache/bcache и тому подобных,
Опять же - см. выше. Подпорки или не подпорки - вопрос эстетики и на результат в конечном итоге влияет слабо. Что нового эта технология привносит? Или что начинает работать лучше чем было? Иначе какой же это козырь относительно других?
> перемещая нужные данные на ssd для быстрого доступа.
Спору нет - фича полезная. Но опять же - такое и btrfs чисто технически может.
> raid-z сильно интересен, ибо близок к parity declustered raid, а не подпорки
> типа raid5/6.Ок, сам по себе raid-z не самая плохая штука. Как RAID. Как считается parity в RAID5/6 мне не особо нравится, недостаточно generic схемы. Тем не менее, в RAIDовых вопросах btrfs интересен тем, что технически он может рулить уровнем RAID-а пообъектно. Так что ценные файлы можно хранить с бОльшим расходом места, а барахло можно например по скорости оптимизировать, а если продолбается - "еще раз закачают, не развалятся". Ну там отчеты бухов - они более важны чем видео с корпоративного бухалова. Ну или мои программы мне нужнее чем допустим мувик с торентов. Ибо переписывать пол-проги при крахе обидно, а мувик с торента я еще раз перекачаю, если оно того вообще стоит.
> Мало?
Да вроде не дофига.
> около 10% если я правильно помню документ. А за ним лесть лениво.
Сдается мне что этот процент весьма варьируется в зависимости от ворклоада, конфиги и прочая. И далеко не всегда 10%. Кстати насколько всем надо 169Тб тома - видно хотя-бы потому что поддержку всего этого в EXT4 и тулсы запилили относительно недавно, хотя дисковый формат как бы не возражал против этого достаточно давно.
> Дисковая полка от CS9000. 5U84 в 2х raid-z. SAS, PCIe v3, LSI
> чип. Винты какие-то WD тюнинг не помню. Да и не я делал. Я лишь видел документы.Там еще поди роялит CPU, память и прочее. А в чем пойнт спрашивать "сколько на этом выжмет ZFS"? Думаешь, я побегу собирать такую конфигу и измерять? Специально для тебя?
> А в EXT4 например экстент может быть 128Мб за 1 присест. Некая разница с 2Мб, да?Хотите скажу страшную тайну - реальных таких размеров не бывает. Да и размер группы не позволит это сделать.
и mballoc не позволит выделить такой размер - ну не умеет он как не старайся. Не затачивали его под это.
Так что не надо рассказывать сказки. То что теоритически так можно сделать - то это не значит что так сработает.> А большая нагрузка - это работа со скоростями близкими к скорости линейного доступа накопителя.
Большая нагрузка это когда SAS шина не успевает за дисковой полкой. а потом ложится PCI-e. А диски еще позволяют дальше качать.
> Кэп намекает что 10 серверов с 16Тб дисков каждый имеют все основания работать лучше чем 1 сервак с 160Гб переросточным диском. Меньше мест для bottleneck-ов.
Кэп намекает что 10 серверов с таким количеством дисков жрут сильно больше электричества требуют в 10 раз больше площащи под датацентр. Понимаешь в чем дело... у нас объемы измеряются Pb, а не Тb.. ну там хранилище на 10Pb, или 60Pb.. сколько серверов потребуются с 16T дисками? а сколько с 160T?
> Это очень нишевой "плюс архитектуры", нужный немногим. Обычно всем нужна прежде всего файловая система все-таки.А нам не нужна - представляете? даже вредна. Отказ от posix уровня дает +30% производительности.
зачем это надо.. Да хотя бы для Swift хранилищь или чего другого object storage или для HPC.> Не вижу чего ради оно должно считаться жирным плюсом "само по себе"
Остальной бред поскипан. Райд по объектам весьма частный случай parity declustering. Который опять же придуман был не сотрудниками btrfs.
> С хрена ли оно плюс, если так или иначе объединять блоки умеют все современные ФС?Знаете ли есть разница объединить за 1с или за 200с. это разные интервалы. я не зря сказал очень ленивые.
> перемещая нужные данные на ssd для быстрого доступа.
> Спору нет - фича полезная. Но опять же - такое и btrfs чисто технически может.Технически это может любая FS, а в рабочем состоянии есть только в zfs.
> Опять же - см. выше. Подпорки или не подпорки - вопрос эстетики и на результат в конечном итоге влияет слабо.
так вы определитесь - возможность встроить кэш в FS это полезная штука или на результат не влияет? а то вы уже запутались :)
Вот к примеру свеже убитый ext4 том - из-за raid mirror на котором лежал журнал этой FS. из-за того что ext4 зачем-то пихает в журнал все директории с которыми работает при lookup - даже при no_atime - получили кашу.
а всего-то raid начал синкать диски в момент journal replay. Итог убитый диск и 2 дня на написание инструментария по выколупывания данных.> Кстати насколько всем надо 169Тб тома - видно хотя-бы потому что поддержку всего этого в EXT4 и тулсы запилили относительно недавно, хотя дисковый формат как бы не возражал против этого достаточно давно.
Поддержку 128Т запилили. причем около года назад - до этого e2fsck корежил файлы за пределами 32T. Режим over 128T пока не тестирован в e2fsprogs и ext4. честно. Причем я знаю до сих пор места в e2fsprogs которые могут выстрелить при работе с дисками в 128Т и данные будут частично поехерены.;
Так что на свой страх и риск..
> Хотите скажу страшную тайну - реальных таких размеров не бывает.С фига ли? Потому что вам с вашим ZFS так неудобно?
> Да и размер группы не позволит это сделать.
Не позволит сделать ... что? Экстент 128 метров? IIRC группы вроде обычно крупнее 128Мб.
> Так что не надо рассказывать сказки. То что теоритически так можно
> сделать - то это не значит что так сработает.Тем не менее, я полагаю что верхний лимит здорово больше чем 2Мб. Так себя обрубить при техническом лимите в 128 было бы глупо.
> Большая нагрузка это когда SAS шина не успевает за дисковой полкой. а
> потом ложится PCI-e. А диски еще позволяют дальше качать.Скорее это дурной переросток с дурными bottleneck-ами. Надо же какое открытие - оказывается PCI-E тоже можно тормознуть! Если сильно постараться.
> Кэп намекает что 10 серверов с таким количеством дисков жрут сильно больше
> электричества требуют в 10 раз больше площащи под датацентр.А также работают быстрее. За счет отсутствия кучи дурных bottleneck. Хотя тут еще зависит от того что сервак с этой кучей данных делает.
> там хранилище на 10Pb, или 60Pb.. сколько серверов потребуются с 16T
> дисками? а сколько с 160T?Ну ок, убедил, у вас и правда дохрена данных. Так понятнее зачем вам такие странные конфиги.
> А нам не нужна - представляете? даже вредна. Отказ от posix уровня
> дает +30% производительности.А если всю операционку переписать на хардкорном асме, оптимизнув под проц который в вон той машине - будет совсем крутота. Правда, рулить ОС и развивать ее будет неудобно. По каким-то таким причинам оси на асме целиком и не пишут. И использовать конструкции без ФС нынче желанием не особо горят, невзирая на меньший оверхед. Админить неудобно. Не, я видал экспонаты и покруче, но это была узконишевая специализированная хрень, абсолютно не гибкая. И поэтому у тебя ее никогда не будет, несмотря на то что мысль лить с диска в сеть 10Гбит железкой кушающей несколько ваттов, мизерного размера, вместо здоровенного сервера - смотрится круто. На первый взгляд. А на второй оказывается что оно из-за предельной оптимизации не гибкое.
> зачем это надо.. Да хотя бы для Swift хранилищь или чего другого
> object storage или для HPC.На практике я вижу уход от использования подобных технологий в сторону нормальных файловых систем. И вероятно nodatacow был привинчен ораклем как раз чтобы ФС превратилась в относительно тонкий слой, когда она не очень мешается БД (особенно своим CoW), но все-таки является для админа ФСом, с работающими на ней позиксными тулзами.
> Остальной бред поскипан. Райд по объектам весьма частный случай parity declustering.
Тем не менее, достаточно логично сделано, имхо.
> Который опять же придуман был не сотрудниками btrfs.
Нынче придумано много чего. Вопрос в том кто и как это скомпонует и как это работать будет
> Знаете ли есть разница объединить за 1с или за 200с. это разные
> интервалы. я не зря сказал очень ленивые.IIRC такие вещи в ряде ФС настраиваются. У бтрфс даже вроде есть нужные рукоятки. Я правда не собираюсь продалбывать 200 секунд данных в случае краха/слета питания/чтотамеще, поэтому в такие дебри не лез. Но помню что видел рукоятки для этого у несколких ФС. По поводу чего не допираю почему это преподносится как эксклюзивный плюс, опять же.
> Технически это может любая FS, а в рабочем состоянии есть только в zfs.
Это при том что ты сам кивал на системы перемещения/кеширования? Вот это я понимаю, лицемерие во весь рост.
> так вы определитесь - возможность встроить кэш в FS это полезная штука
> или на результат не влияет? а то вы уже запутались :)Смотря какой кэш и что это даст. Если кэш в RAM и с управлением памятью как в ZFS - себе такое "счастье" оставьте, имхо. А в целом я не заклинен на тех или иных концепциях. В пингвине стандартная практика - делать так как лучше работает, а не так как расово верно. Поэтому если где-то кэш в ФС лучше работает - пусть в ФС будет, мне не жалко. Но тогда пусть нормально с ядром дружит на предмет возможности этот кэш урезать при необходимости выделить память программам. Иначе - нафиг нужно такое счастье. Управление памятью - прерогатива ядра. И если ФС не хочет нормально дружить с ядром по этому поводу - пусть идет в пень.
> а всего-то raid начал синкать диски в момент journal replay. Итог убитый
> диск и 2 дня на написание инструментария по выколупывания данных.Бывают в жизни огорчения. Правда звучит как-то странно - а зачем что-то делать с журналом при noatime и только чтении?
> Поддержку 128Т запилили. причем около года назад - до этого e2fsck корежил
> файлы за пределами 32T. Режим over 128T пока не тестирован в
> e2fsprogs и ext4. честно.Да потому что такие переростки используются полутора человеками на всю планету. Ну вот они и будут все грабли на свой лоб собирать. Чем менее популярная конфига - тем выше вероятность что будут какие-то проблемы которые вы первыми на планете обнаружили.
> Так что на свой страх и риск..
Да кто бы сомневался. А вон у бздюков ZFS вис из-за нереализованного sendfile в свое время, что не помешало этим упырям заявить что оно "стабильное". И историю заката солнца вручную на лисяре можно найти. При том ок, конкретно тот случай они в утилиты втрамбовали. А еще 100500 вариантов того как оно порушится при вылезании бэдсектора?
> 1) Жрёт оперативку тоннами под свой ARC, игнорируя настройки ограничений и линуксовый
> VFS.3GB она жрёт, для сервера это нормально. И пусть жрёт. А на телефоне или некоговне эта ФС
не нужна. Это серверная ФС.> 2) Имеет какую-то упоротую концепцию снимков-клонов - например, чтобы сделать клон (он
> же r/w-снимок), нужно сначала сделать обычный r/o-снимок, и только с него
> уже делать клон. Какой кретин это придумал?Это твоё личне мнение. Ни чуть не авторитетное. Меня эта вполне логичная схема
устраивает. Да я используюи 2 команды вместо одной, однако проблем с тормозами как
записываемых снапшотах lvm у меня нет.
> 3) На Линуксе ZFS сливает в скорости самым медленным линуксовым ФС, за
> исключением некоторых узких юзкейсов типа огромных RAID-массивов.Факты ? У меня на домашнем компе ZFS на RAID-Z работает в на 60%-80% чем xfs +RAID-5
mdadm. Да raid бедненький на 4-е диска. Но факт на лицо.
> 4) Имеет несовместимую с ядром лицензию, из-за чего приходится сношаться с initramfs
> и прочим дерьмом.Кошерность лицензий тут причём ? Если ФС крэшится, то это не ФС. Зачем с ним (initramfs) сношаться ? Если у Вас руки из жопы растут, это не значит, что тоже самое и с
другими людьми происходит. Поставьте себе Windows, и не ходите сюда.> 5) Через раз при загрузке не может смонтировать корень и вываливается в
> шелл.См. предыдущий пункт.
> Расскажи ещё про самую лучшую ФС, клоун.
ПНХ, е%4ан.
> Показать цитату целикомПоказать всю переписку
Ты тупой что-ли ? Пост выше смотри. Список открытых багов присутствует. Или не осилил
албанский ?
>[оверквотинг удален]
>> Факты ?
> Многочисленные тесты того же фороникса.
>> Кошерность лицензий тут причём ?
>> Поставьте себе Windows, и не ходите сюда.
> Вот тебе как раз и стоит навернуть венды, если тебе кошерность лицензий
> ничего не значит.
>> Зачем с ним (initramfs) сношаться ?
> Расскажи мне как иначе использовать в Линуксе ZFS на корне.
>> Список открытых багов присутствует
> Покажи программный продукт, в котором нет открытых багов, клоун недоразвитый.Всё понятно ... ни одного адекватного ответа от тебя не будет. Каникулы начались.
Устроим замер письками. Ты ведь ради этого тут ?Итак, первый вопрос: "Как использовать ZFS на руте линукс?" Ответ, - примерно вот так:
8187:root@хххххх # mount | grep zboot
zboot/ROOT on / type zfs (rw,relatime,xattr)
zboot/ROOT/tmp on /tmp type zfs (rw,xattr)
zboot/ROOT/var on /var type zfs (rw,xattr)
Кури мануалы, рукожопый.>> А меня нет. Я не люблю алогичный перемудрёный shit.
Тоесть ты просто, непонимаешь зачем он нужен и что это такое. И как snapshots связаны с shift ? Ты тупица даже мануал не прочитал. Shift это для дискового пула, он размер физического блока на диске указывает.
> Многочисленные тесты того же фороникса.О да это аргумент :) И какой ещё аргумент :) А у меня в продуктиве все результаты говорят об одном, - в жопу другие ФС (кроме zfs и xfs), если есть выбор. Комбинация стабильности и производительности для софтовых рейдов в пользу ZFS.
А если рейда нет, то и ничего кроме xfs не нужно. Компренде ?
> Вот тебе как раз и стоит навернуть венды, если тебе кошерность лицензий ничего не значит.
Я винду не осилил. С 1991-го года любовь *nix. И эру дос и винды я пропустил. Линукс ваш до 2007-го года был страшным говнищем, которое в продуктиве стрёмно использовать было. Но он дорос :) и теперь я пользуюсь и им в том числе. А ты, пацан с грязной попкой, учи матчасть.
> Покажи программный продукт, в котором нет открытых багов, клоун недоразвитый.
Расскажи мне дебилушка, как в продуктиве можно использовать ФС которая крэшится и теряет данные ????
Всё, данный персонаж в игноре. На брызги слюной больше реагировать не намерен.
> 3GB она жрёт,Вообще-то оно настраивается. Но превращать юзеря в менеджер кэша с педальным приводом - это как-то криво. И к тому же тормозить начнет если кэш урезать - в самом ZFS нечему работать быстро, особенно с всякими маркетоидными сказками про фрагментацию и про то как CoW в дефраге "не нуждается". А нормальный вариант - если система при душняке с памятью сможет отобрать у ФС кусок кэша. Гарантированно отобрать, а не "как выйдет". Иначе программы будут сыпаться по ошибке malloc() или того хуже возбухнет OOM-killer.
> для сервера это нормально.
Нет, такое управление памятью - не есть нормально. Это костыли и педальный привод.
> И пусть жpёт.
Проблема не только и не столько в том что жpeт. А в том что когда память понадобилась другим, ее нельзя гарантированно отобрать, ибо этот механизм не интегрирован с управлением памятью ядра. На файлсервере где ничего не запущено это может и не проблема, а на всем остальном зато будет совсем не прикольно, когда программы не получат память и осыпятся лишний раз. Будь это сервер приложений, сервер БД, рабочая станция, наконец - там такое поведение уже совсем не айс. А для БД там вообще отдельное западло в виде CoW припасено.
> Это серверная ФС.
Уточним: файлсерверная-only. Ибо серверы бывают разные, далеко не все из них - файлсерверы.
> Это твоё личне мнение. Ни чуть не авторитетное. Меня эта вполне логичная
Чего в этом логичного? По логике вещей снапшот == набор блоков. Ему все-равно, будут там что-то дописывать (тогда CoW сделает выносок вбок, записав изменения относительно зафиксированного набора блоков) или будут сугубо readonly пользоваться.
> записываемых снапшотах lvm у меня нет.
Снапшоты вне файловой системы обречены быть субоптимальными, так или иначе.
> Факты ? У меня на домашнем компе ZFS на RAID-Z работает
> в на 60%-80% чем xfsВ? На? Или "чем грузины"? Нельзя ли уже определиться в показаниях? И да, заодно не забудьте рассказать что будет если забить пул процентов на 80+ и так и оставить. Это конечно не айс, но для домашнего пула ожидаемо, ибо никто не будет расширять его дисками до бесконечности. А у ZFS - ни вам дефрагера нормального, если CoW фрагментов навалил, ни нормального изъятия диска из пула. Очень удобно и производительно, блаблабла. Изен тут уже достиг мегапроизводительности - около 6мб/сек на шпиндель. Он конечно клоун, но тот факт что многодисковый пул можно загадить, а пролечить иначе чем пересборкой пула с удвиганием всех данных не получится - как-то не очень приятен, а?
> Кошерность лицензий тут причём ?
При том что
1) Никогда не будет в майнлайне. И поэтому не будет удобен в использовнии/out of the box.
2) Число тех кто работает над ФС в майнлайне - достаточно убедительное.> другими людьми происходит. Поставьте себе Windows, и не ходите сюда.
Это вам с вашими серебряными пулями виндоус нужен. А в лине навалом ФС и тому есть вполне объективные причины, если что.
> Проблема не только и не столько в том что жpeт. А в
> том что когда память понадобилась другим, ее нельзя гарантированно отобрать, ибо
> этот механизм не интегрирован с управлением памятью ядра. На файлсервере гдебугага. на этом я читать закончил. 294ый дурачек в очередной раз зашел на ресурсик байки потравить о чем-то что он даже в глаза не видел.
мне вот, видимо, приснилось что после того как я mysql поставил на файлсервер и пустил на него запросы, память мускл взял себе сколько нужно, 60 Гб, да.
> файлсервер и пустил на него запросы, память мускл взял себе сколько
> нужно, 60 Гб, да.Зная твой уровень компетенции я вовсе даже и не сомневаюсь что ты в состоянии мониторить все сбои которые возникают при работе системы, ну конечно. А так то да - failed requests будут не у тебя а у юзерей, которые результатами твоей жизнедеятельности пользуются.
"Взял 60Гб" - это ни о чем в системах с динамическим выделением памяти, дурилка ты картонная.
>> файлсервер и пустил на него запросы, память мускл взял себе сколько
>> нужно, 60 Гб, да.
> Зная твой уровень компетенции я вовсе даже и не сомневаюсь что ты
> в состоянии мониторить все сбои которые возникают при работе системы, ну
> конечно. А так то да - failed requests будут не у
> тебя а у юзерей, которые результатами твоей жизнедеятельности пользуются.
> "Взял 60Гб" - это ни о чем в системах с динамическим выделением
> памяти, дурилка ты картонная.напишу полностью, раз ты включаешь(или не включаешь?) режим дауна: взял 60Гб из тех которые до этого "брал" zfs. что твой высер о не возможности отобрать помяти, высеры про OOM и прочее это вот показывает как ложь.
> напишу полностью, раз ты включаешь(или не включаешь?) режим даyна: взял 60Гб из
> тех которые до этого "брал" zfs.Для тех кто на бронетранспортере: проблема в том что этот механизм НИКАКИХ ГАРАНТИЙ НЕ ДАЕТ, в отличие от. В нормальных реализациях ядро может форсированно отобрать память у кэша (кэш на запись даже может быть принудительно скинут на диск с целью отбора у него памяти). А тут кэш "как-то" адаптируется, конечно, но ГАРАНТИЙ никто не даст. Так что если программа попросит памяти (особенно резко и много) - она вполне может столкнуться с ситуацией когда этой самой памяти у ядра нет. И ядро не сможет ЗДЕСЬ И СЕЙЧАС память добыть. А то что оно там потом адаптируется - это все прекрасно, но запрос на выделение памяти "вон той программе" уже обломался и программа пошла лесом. Потенциально завалив какие-то операции по нехватке памяти. А оно такое надо??? Использовать такое управление памятью везде кроме файлсерверов которые эксклюзивно заняты работой с ФС и ничего не гоняют - заявка на запрыг по граблям.
> что твой высeр о не возможности отобрать помяти, высеры про OOM и прочее
> это вот показывает как ложь.Нет, тигра, это показывает лишь то что тут есть парочка поленьев, которые в самых базовых алгоритмах, типа управления памятью - ни в зуб ногой.
Я тебе открою страшную тайну - ядро не может просто так отобрать память у файловой системы. Оно может только попросить и при этом просить акуратно - что бы не войти в рекурсию.
Но FS может игнорировать этот запрос и забить.
> Я тебе открою страшную тайну - ядро не может просто так отобрать
> память у файловой системы. Оно может только попросить и при этом
> просить акуратно - что бы не войти в рекурсию.Да, ядро так "аккуратно" просит, что может аж форсированно выжать кэша на диск, чтобы память которая под него занята все-таки отобрать. Что разок даже сыграло дурную шутку, икнувшись в виде 12309, т.к. если это флешка со скоростью записи мег в час, а кэш отрос до огромных величин - память, конечно, выделится. И даже успешно. Когда-нибудь, когда оно на флешку накапает. Но юзер к этому моменту успеет обложить матом все вокруг, глядя на висящую полчаса программу. Сам факт таких багов намекает что оно не только работает но и делает весьма эффективно. Иногда - на свой зад, как оказалось :).
> Но FS может игнорировать этот запрос и забить.
ФС в mainline ядре пингвина - ну уж наверное кернел сам с собой может договориться. А ZFS - таки да, белая ворона, живет своей жизнью. С ним фиг договоришься.
>> Я тебе открою страшную тайну - ядро не может просто так отобрать
>> память у файловой системы. Оно может только попросить и при этом
>> просить акуратно - что бы не войти в рекурсию.
> Да, ядро так "аккуратно" просит, что может аж форсированно выжать кэша на
> диск, чтобы память которая под него занята все-таки отобрать. Что разок
> даже сыграло дурную шутку, икнувшись в виде 12309, т.к. если этоесть смешнее баг - я его видел и относительно новых ядрах.
http://h10025.www1.hp.com/ewfrf/wc/document?cc=us&lc=en&docn...
>> Но FS может игнорировать этот запрос и забить.
> ФС в mainline ядре пингвина - ну уж наверное кернел сам с
> собой может договориться. А ZFS - таки да, белая ворона, живет
> своей жизнью. С ним фиг договоришься.Любая FS может игнорировать.
> даже сыграло дурную шутку, икнувшись в виде 12309, т.к. если это
> есть смешнее баг - я его видел и относительно новых ядрах.Забавно что те кто описал баг - признают что кривая конфигурация:
Answer/Solution
In this case, the server had only 260 GB memory and was not properly sized for the intended workload. As buffer use increased and available memory reached near zero, although swapping was enabled (vm.swappiness = 60), once available memory became extremely low, too many processes attempted to reclaim memory simultaneously causing spinlock contention. Therefore, the normal Out-Of-Memory process killers ("OOM-killer") and/or swapping could not take place.
То-есть, памяти заведомо не хватало а когда наступил душняк - все резко ломанулись, настолько что даже своп и oom-killer в обломе оказались. То что система при этом совсем виснет - это таки баг, но он провоцируется дурной конфигурацией, которой заведомо не хватало памяти для нормальной работы.> Любая FS может игнорировать.
Но не игнорирует по факту. И почти все кэши ядро может в результате отобрать. Что позволяет им быть немеряного размера пока на память никто не претендует и сдуваться если память кому-то все-таки понадобилась. И как по мне - интеграция этой механики с ядром - внушает больше доверия чем то что в ZFS, живущее своей жизнью.
>4) Имеет несовместимую с ядром лицензию, из-за чего приходится сношаться с initramfs и прочим дерьмом.
>5) Через раз при загрузке не может смонтировать корень и вываливается в шелл.Линуксопроблемы
На FreeBSD еще ни разу 5) не наблюдал.
> На FreeBSD еще ни разу 5) не наблюдал.Да фрибздельников послушать - так ZFS был стабилен даже когда там стабильно вис sendfile().
>> На FreeBSD еще ни разу 5) не наблюдал.
> Да фрибздельников послушать - так ZFS был стабилен даже когда там стабильно
> вис sendfile().бабуля рассказывала?
> бабуля рассказывала?Да, бабулю звали "список рассылки нжинкса". Такое вот странное имя у этой бабульки.
>> бабуля рассказывала?
> Да, бабулю звали "список рассылки нжинкса". Такое вот странное имя у этой
> бабульки.ты даже правильно название написать не можешь, о чем тут можно говорить-та:\
> Мдя, качество коммьюнити определяется его составом.Именно так.
> Опеннет опустился ... какие-то малограмотные дети всякую фигню пишут
Так не пишите. Зачем вы это делаете?
> Очень радуют стабильность, производительность ZFSonLinux.
По сравнению с чем?
> brtfs настолько сырая и кривая,
Ее то допилят. И она таки в майнлайне. Т.е. будет работать out of the box. Оракл и зюзя уже поддержку оказывают. А вот устройство ZFS не подходящее под БД, дурное управление памятью кеша, тормозной дизайн без нормальных экстентов, техническую сложность изъятия дисков из пула и прочие прелести - никто по простому и быстрому в ZFS не починит. И вообще, если все это починить, получится иная ФС. Ну там наподобие btrfs, например...
>А вот
> устройство ZFS не подходящее под БД, дурное управление памятью кеша, тормозной
> дизайн без нормальных экстентов, техническую сложность изъятия дисков из пула и
> прочие прелести - никто по простому и быстрому в ZFS не
> починит. И вообще, если все это починить, получится иная ФС. Ну
> там наподобие btrfs, например...Опять эта чушь про неподходящий для БД дизайн... Рукожопые идиоты могут с ФС натворить всё что угодно.
Короче мануал в руки:
http://www.oracle.com/technetwork/server-storage/solaris/con...
Всё что вы написали такая махровая чусь новичка которы просто даже документацию не осилил.И да ! В жопу религиозных фанатиков ! Прагматизм рулит.
> Опять эта чушь про неподходящий для БД дизайн...Кто же виноват что CoW делает примерно то же что и журнальная логика БД?
> Рyкожопые идиоты могут с ФС натворить всё что угодно.
В данном случае дело отнюдь не в руках админов а в том что встречаются два алгоритма делания одного и того же. И ничего хорошего из этого не получается. Ты вообще в курсе как работает журнальная механика, транзакции и CoW? Если да - должен бы догадаться что за счет двойного журналирования возможно размножение работы в несколько раз. Работать как-то конечно будет, но скорость будет субоптимальной и постепенно все сильно заcpeтся фрагментами, которые по большому счету вообще не должны были появляться, т.к. БД никогда не надеялась на такие услуги и все что касалось журналирования делала сама. А поскольку дефрагера нету - станет вообще совсем хорошо.
> Короче мануал в руки:
Оракл как честный капиталист при желании клиента забить микроскопом гвозди - с удовольствием продаст и микроскоп и гвозди. И даже расскажет как оптимальнее колошматить, в надежде что клиент придет за добавкой. Но это не означает того факта что колошматить микроскопом гвозди - оптимальное решение. Молотком удобнее. А вы почему-то отсылаете меня к чтению мануала по колошматингу микроскопом.
Знаете, а вот Оракл явно в курсе проблемы. И поэтому когда btrfs еще только дизайнили, они уже нахлобучили архитекта чтобы он что-нибудь придумал по этому поводу. И он таки придумал - nodatacow/chattr +C. А в ZFS нам и дальше полощут мозг о том как оно не мешается, как не нyжен дефрагер и чего там еще.
> Всё что вы написали такая махровая чусь новичка которы просто даже документацию
> не осилил.Читать документацию без включения головного мозга и осознания алгоритмики лежащей в основе процессов - удел специально дрессированных обезьянок, каковой вы и являетесь, судя по вашим сообщениям. Ибо основ алгоритмики не знаете, зато рассказы о том как все крЮто из вас так и прут.
> И да ! В жoпу религиозных фанатиков ! Прагматизм рулит.
Вы решили рассказать мне почему вы пойдете в жoпу? Как оригинально! И да, я как раз мыслю вполне рационально и прагматично. И даже применяю оптимизацию - "forward thinking". Нечто типа branch prediction, когда анализируется не только что есть сейчас, но и что скорее всего будет в ближайшем будущем.
>> Опять эта чушь про неподходящий для БД дизайн...
> Кто же виноват что CoW делает примерно то же что и журнальная
> логика БД?кто же виноват что ты - дэбил и ниасилил документацию открыть/почитать? это тебе не картинки на "авторитетном" ресурсе фороникс рассматривать..
>[оверквотинг удален]
> В данном случае дело отнюдь не в руках админов а в том
> что встречаются два алгоритма делания одного и того же. И ничего
> хорошего из этого не получается. Ты вообще в курсе как работает
> журнальная механика, транзакции и CoW? Если да - должен бы догадаться
> что за счет двойного журналирования возможно размножение работы в несколько раз.
> Работать как-то конечно будет, но скорость будет субоптимальной и постепенно все
> сильно заcpeтся фрагментами, которые по большому счету вообще не должны были
> появляться, т.к. БД никогда не надеялась на такие услуги и все
> что касалось журналирования делала сама. А поскольку дефрагера нету - станет
> вообще совсем хорошо.специалистам дефрагер заменяет мозги/способность усваивать информацию из документации? или просто на Авторитетном Ресурсе хабарахабар никто еще не написал какие кнопки жать чтобы победить эту "проблему"?
> А вы почему-то отсылаете меня к чтению мануала по колошматингу
> микроскопом.он просто еще не знает что ты полный дуралей и надеется на чудо - что ты таки откроешь док-цию и найдешь нужное. новенький, наверное. или не рассмотрел дурак294 в ананиме, хз.
> Знаете, а вот Оракл явно в курсе проблемы. И поэтому когда btrfs
> еще только дизайнили, они уже нахлобучили архитекта чтобы он что-нибудь придумал
> по этому поводу. И он таки придумал - nodatacow/chattr +C. А
> в ZFS нам и дальше полощут мозг о том как оно
> не мешается, как не нyжен дефрагер и чего там еще.а zfs, между делом, работает сегодня (вчера/позавчера/пару лет как) а вот твой прогноз "через год" уже почти наполовину обгадился ;-)
> Читать документацию без включения головного мозга и осознания алгоритмики лежащей в основе
> процессов - удел специально дрессированных обезьянок, каковой вы и являетесь, судя
> по вашим сообщениям. Ибо основ алгоритмики не знаете, зато рассказы о
> том как все крЮто из вас так и прут.детонька, ты ток не обижайся, но тебе _показалось_ что не есть обезьянка и обладаешь мозгом, серьезно.
Вы с бармаглотом смотритесь клоунами, srsly.
> Вы с бармаглотом смотритесь клоунами, srsly.лучше уж клоуном смотреться, чем быть им. тяжело тебе, наверное, быть клоуном, да?
> лучше уж клоуном смотреться, чем быть им."Если нечто выглядит как клоун и ведет себя как клоун, мы называем это клоуном".
> Вы с бармаглотом смотритесь клоунами, srsly.Они умеют читать документацию. Чем гордятся. Мозгом правда при этом пользоваться не умеют, но в силу этого факта - не замечают каких либо проблем. Зато их хорошо заметно тем у кого мозг не атрофировался. Этим мегакулсисопы и доставляют: соотношение апломба vs квалификация очень уж анекдотичное. У обоих красавчиков.
> кто же виноват что ты - дэбил и ниасилил документацию открыть/почитать? это
> тебе не картинки на "авторитетном" ресурсе фороникс рассматривать..Это вы - два баклана, которые "умеют читать мануалы", но хронически не умеют пользоваться головным мозгом и не имеют понятия о самых базовых алгоритмах в основе БД и ФС. Я теперь понимаю почему у дешевых хостеров такая поганая репутация. Ибо оказывается даже *никсоид может быть эникеем позорным, не знающим самых основ и не умеющим пользоваться головным мозгом.
> специалистам дефрагер заменяет мозги/способность усваивать информацию из документации?
Специалистам мозги позволяют понимать что и как работает и почему оно работает именно так. А также насколько это (не)оптимально и что и в какую сторону следует крутить. Потому что они могут в своей голове представить как работает "вон тот алгоритм" и прикинуть "а что получится, если...". Ну так вот, моего мозга вполне хватает для того чтобы просчитать что получится когда CoW логика встретится с журнальной и транзакционной логикой базы, делавшейся под generic файловые системы без допущения о свойствах ФС. Получившаяся картина мне не нравится ибо там много явно лишних операций. Оверхед буквально в разы.
Но да, работодателя можно разуть на более мощный сервер, юзерам объяснить что загрузка сайтов по хренадцать секунд - "и так сойдет". И вообще, если на сайт заходит более 2 человек в неделю - разослать предупреждение "ваш сайт слишком грузит сервер, перейдите на более дорогой тариф". При таком раскладе оверхед при записи в базу разика в 2-3 никто и не заметит. Кроме тех кто в теме немного разбирается и потому догадывается о эффективности заколачивания гвоздей микроскопами, невзирая на тыкания в мануалы "как правильно колотить микроскопом по гвоздю".
> или просто на Авторитетном Ресурсе хабарахабар никто еще не написал какие
> кнопки жать чтобы победить эту "проблему"?Без понятия: я на хабра-швабру последний раз ходил сколько-то месяцев назад. А на уровне алгоритмики мне как-то понятно что это не лечится никак, кроме как отключением CoW-механики, которая совсем не друг логике работы большинства баз.
> он просто еще не знает что ты полный дуралей и надеется на
> чудо - что ты таки откроешь док-цию и найдешь нужное.Найду что? ZFS научился отключать CoW? И мне покажут рукоятки для этого? А может даже еще и выборочно, по файлам даже? Или может там дефрагер который фрагменты за CoW-ом устранял наконец сделали? И ман покажет как его пинать, вместо маркетингового булшита от саней с кучей *отмазок* почему они это не будут делать?м еще.
> а zfs, между делом, работает сегодня (вчера/позавчера/пару лет как) а вот твой
> прогноз "через год" уже почти наполовину обгадился ;-)Какой крутой и обстоятельный ответ на все претензии. Ну знаешь, EXT2 тоже работает здесь и сейчас, а на "небольшие отличия" - можно в общем то положить, если действовать в твоем духе. Ну а чо, вывалить туда скуль, с 60 гигз памяти даже работать как-то будет, а журналят базы всяко сами. Попробуй ка оспорь...
> детонька, ты ток не обижайся, но тебе _показалось_ что не есть обезьянка
> и обладаешь мозгом, серьезно.Это отдельный вопрос и это мы будем посмотреть. А вот то что я достоверно вижу - так это 2 специально обученные обезьянки. Которые явно не уловили что "насыщает не время, проведенное в столовой, а количество съеденных беляшей". Да-да, это мой ответ про ваши тыкания на мануалы.
>> специалистам дефрагер заменяет мозги/способность усваивать информацию из документации?
> Специалистам мозги позволяют понимать что и как работает и почему оно работает
> именно так. А также насколько это (не)оптимально и что и в
> какую сторону следует крутить. Потому что они могут в своей голове
> представить как работает "вон тот алгоритм" и прикинуть "а что получится,
> если...". Ну так вот, моего мозга вполне хватает для того чтобы
> просчитать что получится когда CoW логика встретится с журнальной и транзакционной
> логикой базы, делавшейся под generic файловые системы без допущения о свойствах
> ФС. Получившаяся картина мне не нравится ибо там много явно лишних
> операций. Оверхед буквально в разы.я повторю последний раз, для дэбилов: это лечится. чтением док-ции. вместо того, чтобы писать многобуквенные высеры ты бы лучше потратил эти 5 минут на поиск ответа. чтобы в очередной (а ты в каждой новости где есть обсуждение zfs так смачно обсираешься) не обосраться. ну и да, уж не себя ли ты имеешь ввиду когда пишешь "Специалистам мозги"? Чисто ради поржать спросил.
> Но да, работодателя можно разуть на более мощный сервер, юзерам объяснить что
> загрузка сайтов по хренадцать секунд - "и так сойдет". И вообще,
> если на сайт заходит более 2 человек в неделю - разослать
> предупреждение "ваш сайт слишком грузит сервер, перейдите на более дорогой тариф".
> При таком раскладе оверхед при записи в базу разика в 2-3
> никто и не заметит. Кроме тех кто в теме немного разбирается
> и потому догадывается о эффективности заколачивания гвоздей микроскопами, невзирая на
> тыкания в мануалы "как правильно колотить микроскопом по гвоздю".ну, пожалуй я сдамся уже.
у тебя там, кстати, не на 1 ли хромосому больше нормального их кол-ва? стойкое чувство имеется что да.
дальше даже не стал читать.
>[оверквотинг удален]
>> если на сайт заходит более 2 человек в неделю - разослать
>> предупреждение "ваш сайт слишком грузит сервер, перейдите на более дорогой тариф".
>> При таком раскладе оверхед при записи в базу разика в 2-3
>> никто и не заметит. Кроме тех кто в теме немного разбирается
>> и потому догадывается о эффективности заколачивания гвоздей микроскопами, невзирая на
>> тыкания в мануалы "как правильно колотить микроскопом по гвоздю".
> ну, пожалуй я сдамся уже.
> у тебя там, кстати, не на 1 ли хромосому больше нормального их
> кол-ва? стойкое чувство имеется что да.
> дальше даже не стал читать.У вас аргументация не техническая, потому инженерам не понятная.
>когда CoW логика встретится с журнальной и транзакционной логикой базы, делавшейся под generic файловые системы без допущения о свойствах ФССкажите, а вот у тех, которые "делались с допущением о свойствах ФС" - у них что же, write-ahead log не пишется?
> - у них что же, write-ahead log не пишется?Пишется. И в этом то как раз грабли. Прикинь, а CoW ведь сделает выносок вбок и для лога (нафига?) и для коммита в основную область базы (опять же, нафига?). В результате появится туева хуча фрагментов которых по изначально задуманной логике вообще быть не должно, т.к. база на самом деле хотела in-place патчинг в паре мест. А CoW трансформировал его в выноски. Потому что работает он так. В результате получится вермишель из кучи выносков по всему диску, при том - неизвестно ради чего. Что еще лулзовее - дефрагера нету, так что выноски останутся в виде вермишели "навечно" :).
Итог? Злостный оверхед файловых операций, в неудачном случае - в разы. И деградация over time по мере эксплуатации. Но про это в маркетинговых буклетах писать стесняются.
тебе объяснить почему Oracle (и вообще серьезные базы) рекомендуют ставить базы не на FS на raw device ?
> тебе объяснить почему Oracle (и вообще серьезные базы) рекомендуют ставить базы не
> на FS на raw device ?Спасибо, я и сам догадываюсь что 2 раза делать одну и ту же по смыслу работу - не совсем эффективно. Но дело в том что админы не хотят админить базы на raw device. Оракл видимо в курсе этого факта. Поэтому у них и появляется требование - ФС которая сможет быть тонкой прослойкой под БД, позволив админам использование привычных утилит, но не слишком мешая базе. Вот CoW тут совсем не в кассу на пути к реализации такой хотелки. Потому и nodatacow.
сырая ещё, поверьте
На каком основании я дожен доверять вашим "вбросам" ? Система в продуктиве уже 5 лет. Два года в продуктив никто её не вводил, - тестировалась. Для Solaris альтернативы вообще нет. Для линукс с прошлого года в продуктиве на высоконагруженных серверах. Да небыло POSIX ACL, был ACL NFSv4. Его под наши задачи хватало, но POSIX ACL ждали. Потерь данных нет, сбоев нет. А вот новомодные ext4 и brtfs похвастаться подобным не могут. Все тестовые инсталляции заканчиваются одним заключением, - сырые и не пригодные к продуктивному использованию. В сухом остатке единственная ФС под linux, кроме ZFS, для наших задач, - это xfs.
Это в каких условиях ext4 начинает терять данные? Для обычного использования они все стабильные.
> Это в каких условиях ext4 начинает терять данные? Для обычного использования они
> все стабильные.
> https://lkml.org/lkml/2012/10/23/690А ничего что этому сообщению полтора года и с тех пор в ext4 были починены data corruption-ы? И да, если вдруг ext4 работает у титанов типа гугли и тому подобных, а у вас теряет данные - вы таки или очень сильно невезучий человек, поймавший баг, возникающий раз на миллиард, или просто спиди-гонщик, что намного вероятнее.
>И да, если вдруг ext4 работает у титанов типа гугли и тому подобных, а у вас теряетГугль просто выключает [при поломне железа, говорят. про [[fsck и]] потерю нанных - не уверен, может просто перезаливают] узел (да! 1 из тыщи-мильона) до следующего (раз в 3 месяца?) приезда инженегра. И _никому это не заметно.
> данные - вы таки или очень сильно невезучий человек
У него нет 0.001 ездового инженегра для починки 1 из 1000000 своих серверов. Неповезло.
> Гугль просто выключает [при поломне железа, говорят. про [[fsck и]] потерю нанных
> - не уверен, может просто перезаливают] узел (да! 1 из тыщи-мильона)Подловил, гад! :). Вот что значит - постоянный посетитель. Тем не менее, если бы у них часто сыпалась ФС - они бы озаботились вопросом что на сервера слишком часто приходится обращать внимание для их починки и нахлобучили бы причастных в багтрекере. Ведь если тебя долбит какой-то баг, заставляющий технарей бросить все и заняться приведением узла в чувство - поневоле пойдешь и поспособствуешь прихлопыванию этого бага. Чтобы сократить затраты на обслуживание серверов.
> до следующего (раз в 3 месяца?) приезда инженегра. И _никому это
> не заметно.Кроме инженегров. И если дохлых серверов по линии файловой системы будет много и часто - придется нанимать много инженегров. А это уже стоит денег.
P.S. а вообще, большинство инсталляций EXTов используют их в режиме журналирования только метаданных, что как бы намекает нам - "пипл хaвает".
> У него нет 0.001 ездового инженегра для починки 1 из 1000000 своих
> серверов. Неповезло.Ну дык. Хочешь сэкономить на инженеграх - пиши баги в багтрекер. Все честно вроде.
> Это в каких условиях ext4 начинает терять данные? Для обычного использования они
> все стабильные.Это после того, как куча дистрибутивов его по умолчанию стала устанавливать и рекомендовать к использованию было. С тех пор не тестировал. Скандалец был занимательный. Теперь никто не рекомендует срочно в продуктив на серверы ext4 ставить .. одумались.
https://patchwork.kernel.org/patch/1635091/
http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
> This can happen if we mount and then unmount the file system fairly quickly, before the log has a chance to wrap. After the first time this has happened, it's not a disaster, since when we replay the journal, we'll just replay some extra transactions. But if this happens twice...Охрененно жизненный юзкейс.
> Это после того, как куча дистрибутивов его по умолчанию стала устанавливать и
> рекомендовать к использованию было.И что? В любом коде бывают баги. При обычном использовании потерять данные в ext4 у меня не получилось вообще ни разу за столько лет. А то что редкие баги, кусающиеся в полнолуние високосного года, при условии что был четверг, прошел дождик и на горе рассвистелись вдруг раки бывают - ну да, и поймать их сложно именно по этой причине: такое сочетание параметров почти никогда не наступает. Поэтому такое не ловится ни автоматическими прогонами тестов, ни обычными юзерями на десктопе. И только 1 счастливчик на миллиард нарывается на такой баг.
> Теперь никто не рекомендует срочно в продуктив на серверы ext4 ставить
Да, конечно. Гугл их уже много лет просто использует. Без всяких рекомендаций. Да и даже местный линуксхрип уж на что кроет пингвин, производительность EXT4 в каких-то странных ситуациях и что там еще. Но про именно осыпон данных ничего не говорил.
Начались каникулы - понабежало экспертов мля. Ща они научат гуглю сервера настраивать. И фэйсбук с его btrfs объяснят какие они лохи.
> Да, конечно. Гугл их уже много лет просто использует. Без всяких рекомендаций.
> Да и даже местный линуксхрип уж на что кроет пингвин, производительность
> EXT4 в каких-то странных ситуациях и что там еще.У Гугла своя специфика - многократное распределенное резервирование .Знаешь что EXT4 у Гугла используется без журнала ? А перешли они с EXT2 из-за скорости ,EXT4 без журнала быстрее .И fsck.ext4 не используется ,если фиксируется сбой данные автоматически переписываются (форматирование +заливка образа) ,опять из-за скорости и надежности -инженеры посчитали что теряется время на проверку и часть файлов может оказаться в lost+found .Так что у Гугла очень специфическое использование .
> У Гугла своя специфика - многократное распределенное резервированиеЕще 1 внимательный :). Это так, НО если бы случались массовые отказы по линии ФС - затраты на обслуживание выросли бы, что все-таки не в интересах гугля. Поэтому вопрос в общем то в том проводится ли разбор полетов и обнаружение багов. Я думаю что проводится.
>> У Гугла своя специфика - многократное распределенное резервирование
> Еще 1 внимательный :). Это так, НО если бы случались массовые отказы
> по линии ФС - затраты на обслуживание выросли бы, что все-таки
> не в интересах гугля. Поэтому вопрос в общем то в том
> проводится ли разбор полетов и обнаружение багов. Я думаю что проводится.со слов людей которые держат сотни кластеров с количеством нод от 5 до 50 тысяч, одина умершая нода в сутки это норма. Так что дешевле дублировать и разворачивать - учитывая что это копия - а значит автоматизировано.
Поэтому проблемы fs гугла волнуют слабо..
> до 50 тысяч, одина умершая нода в сутки это норма.А теперь представим себе что ФС фуфло и дохло бы больше. А оно кому-то надо - дополнительная нагрузку на персонал на ровном месте? Из чувства мазохизма чтоли? Ведь так персонала потребуется больше, а капиталисты - они жадные...
>> до 50 тысяч, одина умершая нода в сутки это норма.
> А теперь представим себе что ФС фуфло и дохло бы больше. А
> оно кому-то надо - дополнительная нагрузку на персонал на ровном месте?
> Из чувства мазохизма чтоли? Ведь так персонала потребуется больше, а капиталисты
> - они жадные...какой персонал? вы о чем? там робот делает.. персонал только читает почту..
> какой персонал? вы о чем? там робот делает.. персонал только читает почту..Обана, кто-то еще научился проходить тест Тюринга и поэтому может детектировать совершенно произвольный развал системы на автомате? :)
>> какой персонал? вы о чем? там робот делает.. персонал только читает почту..
> Обана, кто-то еще научился проходить тест Тюринга и поэтому может детектировать совершенно
> произвольный развал системы на автомате? :)там не детектируют - просто формат - reinstall - resync. они сами писали об этом.
> просто формат - reinstall - resync. они сами писали об этом.А формат что, происходит чисто для профилактики, постоянно? Или все-таки по какому-то поводу?
>> просто формат - reinstall - resync. они сами писали об этом.
> А формат что, происходит чисто для профилактики, постоянно? Или все-таки по какому-то
> поводу?Развал ноды вполне легко детектирует BigTable. после чего ее проще замочить.
> Развал ноды вполне легко детектирует BigTable. после чего ее проще замочить.Вот я и спрашиваю - они там что, научились детектировать совершенно произвольные развалы?
> Это после того, как куча дистрибутивов его по умолчанию стала устанавливать и
> рекомендовать к использованию было. С тех пор не тестировал. Скандалец был
> занимательный. Теперь никто не рекомендует срочно в продуктив на серверы ext4
> ставить .. одумались.А ведь теперь XFS начали рекомендовать. Красные пришли, конец xfs-у. Куда бечь?!
FreeBSD c $SUBJ-ом спасает: уж её-то _не рекомендуют в продакшоны!
>/<
> Это в каких условиях ext4 начинает терять данные? Для обычного использования они
> все стабильные.Обсуждаем же ZFS и большие объемы ?
Проблема начинается с большими данными от 5 и выше терабайт .В некоторых случаях падает индекс (В-дерево) ,проблему частично починили ведением контрольных сумм ,но закавыка осталось (хотя данные и не теряются но нужна проверка разделов ,иначе жуткие тормоза).Поэтому и добавили в ext4 возможность вынести индекс и метаданные в файл или отдельный раздел .Данные черпнутые из толксов на linux.org при обсуждение почему красная шапка не выбрала в новой версии ext4 по умолчанию .
>> Это в каких условиях ext4 начинает терять данные? Для обычного использования они
>> все стабильные.
> Обсуждаем же ZFS и большие объемы ?
> Проблема начинается с большими данными от 5 и выше терабайт .В некоторых
> случаях падает индекс (В-дерево) ,проблему частично починили ведением контрольных сумм
> ,но закавыка осталось (хотя данные и не теряются но нужна проверка
> разделов ,иначе жуткие тормоза).Поэтому и добавили в ext4 возможность вынести индекс
> и метаданные в файл или отдельный раздел .Данные черпнутые из толксов
> на linux.org при обсуждение почему красная шапка не выбрала в новой
> версии ext4 по умолчанию .ext4 спокойно живет на объемах 64-100Т, ну слегка патченый... ну очень патченый.. но живет.
Через пару неделек буду знать как он живет на 160Т per disk, как раз подогнали полку с 6Т винтами.
> ext4 спокойно живет на объемах 64-100Т, ну слегка патченый... ну очень патченый..Линуксрип решил нам рассказать о плюсах опенсорса вообще и линукса в частности - их, оказывается, можно запатчить. А теперь попробуйте такой номер с вашей любимой бздой в каком-нибудь storage appliance :).
>> ext4 спокойно живет на объемах 64-100Т, ну слегка патченый... ну очень патченый..
> Линуксрип решил нам рассказать о плюсах опенсорса вообще и линукса в частности
> - их, оказывается, можно запатчить. А теперь попробуйте такой номер с
> вашей любимой бздой в каком-нибудь storage appliance :).Не поверишь для моей конторы нет разницы. Тем более моя контора и подарила вам ext4.
Так что наслаждайтесь разработкой Алекса и Андреаса.
> Не поверишь для моей конторы нет разницы.И правда, не поверю. Исходя из предыдущих сообщений.
> Тем более моя контора и подарила вам ext4.
> Так что наслаждайтесь разработкой Алекса и Андреаса.Странно, я все-время думал что благодарить надо единолично линуксрипа. А всякие лохи типа Теодора Тсо в эту форумулу чего, вообще не входят? И, кстати, не многовато ли кое-кто на себя берет, учитывая что EXT4 является разогнанным вариантом EXT3, с кучей унаследованного оттуда барахла, а самым крупным отличием являются экстенты. А это, авторов предыдущих ext-ов мы вообще за людей считать не будем? А то как говорится - легко стоять на плечах гигантов.
>[оверквотинг удален]
> И правда, не поверю. Исходя из предыдущих сообщений.
>> Тем более моя контора и подарила вам ext4.
>> Так что наслаждайтесь разработкой Алекса и Андреаса.
> Странно, я все-время думал что благодарить надо единолично линуксрипа. А всякие лохи
> типа Теодора Тсо в эту форумулу чего, вообще не входят? И,
> кстати, не многовато ли кое-кто на себя берет, учитывая что EXT4
> является разогнанным вариантом EXT3, с кучей унаследованного оттуда барахла, а самым
> крупным отличием являются экстенты. А это, авторов предыдущих ext-ов мы вообще
> за людей считать не будем? А то как говорится - легко
> стоять на плечах гигантов.History
ext4 was born as a series of backward compatible extensions to ext3, many of them originally developed by Cluster File Systems for the Lustre file system between 2003 and 2006, meant to extend storage limits and add other performance improvements.[1]историю надо знать.
>[оверквотинг удален]
> И правда, не поверю. Исходя из предыдущих сообщений.
>> Тем более моя контора и подарила вам ext4.
>> Так что наслаждайтесь разработкой Алекса и Андреаса.
> Странно, я все-время думал что благодарить надо единолично линуксрипа. А всякие лохи
> типа Теодора Тсо в эту форумулу чего, вообще не входят? И,
> кстати, не многовато ли кое-кто на себя берет, учитывая что EXT4
> является разогнанным вариантом EXT3, с кучей унаследованного оттуда барахла, а самым
> крупным отличием являются экстенты. А это, авторов предыдущих ext-ов мы вообще
> за людей считать не будем? А то как говорится - легко
> стоять на плечах гигантов.ах да, экстенты и mballoc3 - это как раз то что сделал CFS - персонально Alex. учите историю сударь.
> ах да, экстенты и mballoc3 - это как раз то что сделал
> CFS - персонально Alex. учите историю сударь.Знаешь, если некто заменил в автомобиле двигатель и ездить стало лучше - это еще не синоним того что "сделал весь автомобиль". Оказывается была куча других людей без работы которых ничего не получилось бы и текущее состояние и близко бы не стояло к тому что есть сейчас. Поэтому приписывать все заслуги 1-2 человекам - несколько по ханжески. С таким же успехом можно сказать что Мэйсон в 1 лицо btrfs сделал. А фиг, он сделал костяк алгоритмов. А туеву хучу багфиксов и оптимизаций отпахали другие люди вот.
> С таким же успехом можно сказать что Мэйсон в 1 лицо
> btrfs сделал. А фиг, он сделал костяк алгоритмов. А туеву хучу
> багфиксов и оптимизаций отпахали другие люди вот.Мэйсон наваял кучу дерьмового кода, ничего общего с алгоритмами не имеющего.
Мэйсон вполне себе посмотрел на существующие дизайны и постарался выдернуть все лучшее, оставив за бортом типовые проблемы. И получилось у него в целом получше чем у многих других (в том числе и сановских инженегров). Он не делал алгоритмы, он их комбинировал. И в целом вышло получше чем у многих других.
Почему бы им не написать свой собственный модуль, не основанный на чужом коде, и не лицензировать его под GPL, чтобы он вошёл в ядро Linux?
ZFS - это не только On-Disk формат, ну и куча попутных архитектурных конструкций, таких как многопоточный конвеер ZIO, планирование вводом-выводом на устройства (не знаю, как в ZFS on Linux, но в Solaris оно отдельное от системы), и т. д., так что запаришься его портировать.Но вы можете попробовать :)
Проблемы несовместимости лицензии лялеха со всеми остальными лицензиями - это проблемы лялеха. Что не является поводом с нуля в одиночку писать то, что уже дофига лет разрабатывается, исправляется и обдуманно улучшается достаточно большим количеством людей, которые в этом шарят лучше тебя.
Уж лучше рабочий внешний модуль, чем кривое глюкалово в ядре.
Интересно, когда свежий релиз Sabayon с этим релизом будет
Это вообще не проблема, т.к. линукс уже множество лет поддерживает загружаемые модули и initrd
> Проблемы несовместимости лицензии лялеха со всеми остальными лицензиями
> - это проблемы лялеха.Вот только пингвин появился раньше чем сани решили расщедриться. Так что сани специально создали проблемы, пингвин тут вообще никаким боком. Правда в результате очень большой вопрос - кто кого нагрел. Где сейчас сани, а где пингвин?
Так никто никого не нагрел. Санки отдали свои наработки, кто-то их смог взять, а кто-то нет. Причём тут то, где санки? ZFS-то вот она, работает :-)
> Так никто никого не нагрел. Санки отдали свои наработки, кто-то их смог
> взять, а кто-то нет. Причём тут то, где санки? ZFS-то вот
> она, работает :-)ты тоже даже через браузер ощущаешь жопоболь усёр294 из-за того что "ему" поднасрали с cddl ?)
>> Так никто никого не нагрел. Санки отдали свои наработки, кто-то их смог
>> взять, а кто-то нет. Причём тут то, где санки? ZFS-то вот
>> она, работает :-)
> ты тоже даже через браузер ощущаешь жопоболь усёр294 из-за того что "ему"
> поднасрали с cddl ?)Жалко человека просто :-)
Понабежало жалельщиков. Себя пожалейте лучше. Ну так, например логика btrfs применительно к RAID: есть девайсы. Есть свободное место на таковых. Есть уровни RAID. А дальше тот или иной файл раскладывается на девайсы в соответствии с требованием выбранного для той или иной сущности уровня RAID-а.Кроме всего прочего это означает что оно на уровне дизайна и логики работы может разным файлам разные уровни райда сделать. То-есть не надо принимать никаких жестких решений на уровне ФС, устройств и прочая. Технически оно может рулить с гранулярностью до отдельных файлов. Круто придумано, не так ли? Ведь тезис о том что все файлы одинаково ценны - очень спорный. И так намного гибче и экономичнее управление свободным местом. Хоть в результате и возникает непонятка: "- а сколько свободно?" -> "а как записывать будете?"
>[оверквотинг удален]
> RAID. А дальше тот или иной файл раскладывается на девайсы в
> соответствии с требованием выбранного для той или иной сущности уровня RAID-а.
> Кроме всего прочего это означает что оно на уровне дизайна и логики
> работы может разным файлам разные уровни райда сделать. То-есть не надо
> принимать никаких жестких решений на уровне ФС, устройств и прочая. Технически
> оно может рулить с гранулярностью до отдельных файлов. Круто придумано, не
> так ли? Ведь тезис о том что все файлы одинаково ценны
> - очень спорный. И так намного гибче и экономичнее управление свободным
> местом. Хоть в результате и возникает непонятка: "- а сколько свободно?"
> -> "а как записывать будете?"если ты привык работать за корку хлеба... то да, такая гибкость нужна. Иначе время работы админа который будет настраивать уровни рейда для каждого файла - будет стоить дороже тех данных. В остальных случаях достаточно обеспечить максимальную надеждность.
> если ты привык работать за корку хлеба... то да, такая гибкость нужна.
> Иначе время работы админа который будет настраивать уровни рейда для каждого
> файла - будет стоить дороже тех данных.Много апломба, и всё ни о чем. А знаешь, там можно и не для каждого файла, а для каждого subvolume, например. Как раз гранулярность управления рукояток там достаточно неплохо выбирается. Можно пофайлово, можно по subvolumes/для всей ФС. Так что все эти бла-бла про кучу времени - ни о чем.
> В остальных случаях достаточно обеспечить максимальную надеждность.
А вон гугл например вообще плевать хотел на надежность ФС, им скорость подавай. На чем меня тут кстати особо внимательные индивиды подловили симпатично :).
> Так никто никого не нагрел. Санки отдали свои наработки,
> кто-то их смог взять, а кто-то нет.Ну как бы сабж нам намекает что те кто хотел это делать в лине - тоже нашли вариант. А то что в майнлайне этого не будет - и к лучшему. Глядя на то как оно сделано - в майнлайне должен победить нормальный вариант, где проблемы дизайна не закaпывают под ковер, припудривая маркетинговым булшитом.
> Причём тут то, где санки? ZFS-то вот она, работает :-)
Их уже две. Одна у оракла и другая - у остальных. Похоже работать будет как с UFSами, которых штук пять разных и которые все 5 доброго слова не стоят с точки зрения применяемых там технологий.
> Почему бы им не написать свой собственный модуль,Так и пишут. Передизайнив попутно места с явными тупняками. Btrfs-ом это называется :).
>> Почему бы им не написать свой собственный модуль,
> Так и пишут. Передизайнив попутно места с явными тупняками. Btrfs-ом это называется
> :).чуть больше полугода по твоим прогнозам осталось. как думаешь, успеют, иксперт?;)
> чуть больше полугода по твоим прогнозам осталось. как думаешь, успеют, иксперт?;)Успеют ... что именно? Если не соваться в RAID5/6, btrfs уже вполне прилично работает, даже баги которые в нем давят в новых ядрах - какие-то не особо страшные и все более рутинные/экзотичные. Нормальный такой асимптотический процесс стабилизации качества ПО, ничего такого необычного вроде.
А, да, отдельный привет: разработчики btrfs используют его у себя. На rootfs машин разработчиков. Так что он обречен нормально рабоатать. Да, мне нравится когда кузнец готов одеть свои доспехи и не возражает чтобы по ним #$%нули мечом. Это хороший метод проверки качества работы кузнеца. Отдельные приветы Kibab'у, который делом доказал на что годен фрибзд...
>> чуть больше полугода по твоим прогнозам осталось. как думаешь, успеют, иксперт?;)
> Успеют ... что именно? Если не соваться в RAID5/6, btrfs уже вполне
> прилично работает, даже баги которые в нем давят в новых ядрах
> - какие-то не особо страшные и все более рутинные/экзотичные. Нормальный такой
> асимптотический процесс стабилизации качества ПО, ничего такого необычного вроде.ну т.е. ты уже собсные прогнозы забываешь?;) найди новость про мордокнигу и перечитай свои комменты.
> А, да, отдельный привет: разработчики btrfs используют его у себя. На rootfs
> машин разработчиков. Так что он обречен нормально рабоатать. Да, мне нравится
> когда кузнец готов одеть свои доспехи и не возражает чтобы по
> ним #$%нули мечом. Это хороший метод проверки качества работы кузнеца. Отдельныелол, а остальные, значится, пользуются fat32 и пишут более другие fs, под *nix, зачет.
> приветы Kibab'у, который делом доказал на что годен фрибзд...разговариваешь с голосами в своей голове?;)
> ну т.е. ты уже собсные прогнозы забываешь?;) найди новость про мордокнигу и
> перечитай свои комменты.Еще раз спрашиваю - какой именно Рубикон планируется перейти через полгода? Если коммерческая поддержка крупняком - она *уже* есть у оракла и зюзи. И большинство фич вполне нормально работают. Там нынче в коммитах доминирует в основном костылирование RAID5/6, допиловка send/receive и обезглючинг оного. Остальное вроде вполне стабильно и каких-то особо жутких багфиксов пачками там нету уже.
> лол, а остальные, значится, пользуются fat32 и пишут более другие fs, под
> *nix, зачет.Шиза косила ваши ряды?
>> приветы Kibab'у, который делом доказал на что годен фрибзд...
> разговариваешь с голосами в своей голове?;)Да просто этот кадр писал какой-то драйвер SATA для какой-то мелкой железки, а сам на десктопе в макоси кукует. Наглядно показывая какой из фряхи десктоп - так что даже нужды разработчика не покрывает. Как с реактосом примерно.
>> ну т.е. ты уже собсные прогнозы забываешь?;) найди новость про мордокнигу и
>> перечитай свои комменты.
> Еще раз спрашиваю - какой именно Рубикон планируется перейти через полгода? Если
> коммерческая поддержка крупняком - она *уже* есть у оракла и зюзи.пользователю, по большому счету, насрать, есть ли эта поддержка в случаях когда данные уже просраны из-за "фич" fs.
> И большинство фич вполне нормально работают. Там нынче в коммитах доминируетчто такое "большинство фич" относительно fs? меньшинство реализовано но "не работает"?;)
> в основном костылирование RAID5/6, допиловка send/receive и обезглючинг оного.Остальное
> вроде вполне стабильно и каких-то особо жутких багфиксов пачками там нету
> уже.т.е. эта Замечательная и Прогрессивная fs _сейчас_ годится для использования в где?
>> лол, а остальные, значится, пользуются fat32 и пишут более другие fs, под
>> *nix, зачет.
> Шиза косила ваши ряды?нет, это просто кто-то полностью дэбил, раз "фишкой" fs назвал то, что ее же используют разработчики, в том числе.
>>> приветы Kibab'у, который делом доказал на что годен фрибзд...
>> разговариваешь с голосами в своей голове?;)
> Да просто этот кадр писал какой-то драйвер SATA для какой-то мелкой железки,
> а сам на десктопе в макоси кукует. Наглядно показывая какой из
> фряхи десктоп - так что даже нужды разработчика не покрывает. Как
> с реактосом примерно.во как, то про wifi бредил, щас про sata... ты б спросил уже у него сам, что же он таки писал;) представляю какой силы у тебя случился бы жопный зуд если бы ты хотябы фоточки с bsdcan последнего узрел, лол
>> Еще раз спрашиваю - какой именно Рубикон планируется перейти через полгода? Если
>> коммерческая поддержка крупняком - она *уже* есть у оракла и зюзи.
> пользователю, по большому счету, насpать, есть ли эта поддержка в случаях когда
> данные уже просраны из-за "фич" fs.Как бы это сказать? Чинить сложную ФС под руководством компетентных профи, понимающих как оно работает - лучше, чем колупаться on your own. Особенно если юзерь не эксперт в области. И, кстати, там нынче довольно неплохой арсенал средств починки. Даже недеструктивный тул для вытаскивания "всего что смогли найти" на отдельный диск (по типу небезызвестного в свое время Tiramisu) есть. В отличие от - нахаляву и прямо от разработчиков ФС. Поди плохо, а? А тезис о том что оно при обычной эксплуатации проcиpaет чаще других - уже достаточно спорный, имхо. Большинство кадров с проблемами вылазят с ядрами типа 3.2. Спасибо еще если не 2.6.30. Им первым делом и говорят - ядро обновите. После этого у половины проблемы почему-то отпадают и они убежденно отползают. Наверное, потому что кроме околачивания груш разработчики еще нехило багфиксов вкатили со времен 2.6.30 :).
> что такое "большинство фич" относительно fs? меньшинство реализовано но "не работает"?;)
Как-то так. Из меньшинства: send/receive сделали недавно. Он уже работает, но поток багов касающихся этой фичи в corner cases пока великоват - я бы не стал на эту фичу безоговорочно полагаться. И RAID5/6 пока сырой, на него тоже полагаться не стоит. Остальное вроде работает, откровенных факапов и жутких багфиксов уже не видно что-то.
> т.е. эта Замечательная и Прогрессивная fs _сейчас_ годится для использования в где?Как видишь, годится. С некоторыми оговорками. Где? Ну вон фэйсбучик на своих серверах устраивает тестовые забеги. Разработчики юзают для себя как рутфс. Оракл и зюзя готовы сие поддерживать.
>> Шиза косила ваши ряды?
> нет, это просто кто-то полностью дэбил, раз "фишкой" fs назвал то, что
> ее же используют разработчики, в том числе.Это хороший признак для любой программы. Если программой не хочет пользоваться даже ее разработчик (как Kibab в случае с фряхой, или реактосовцы с реактосом) - тут все понятно. С качеством, фичами и вообще юзабельностью всего этого.
> во как, то про wifi бредил, щас про sata...
Тю, поищи сообщения Kibab-а здесь. Он честно хвастался что писал sata драйвер и признавался что на десктопе у него макосятина. Я конечно понимаю что удар по самолюбию некоторых, но все-таки.
> ты б спросил уже у него сам, что же он таки писал;)
Так он и рассказывал. Попутно с упоминианием что на десктопе у него макось. Поищи в его сообщениях, фигли. Вон там в профайл можно ткнуть и поискать, если так интересно.
> фоточки с bsdcan последнего узрел, лол
Не знаю насчет фоточек, а сообщения Kibab такого плана - как раз на уютненьком опеннетике и опубликованы.
>Так он и рассказывал. Попутно с упоминианием что на десктопе у него макось. Поищи в его сообщениях, фигли. Вон там в профайл можно ткнуть и поискать, если так интересно.А какой-нибудь eCOS тоже нужно разрабатывать, имея на рабочей станции eCOS? User294, годы идут, а ты все никак не поумнеешь.
Кстати сказать, про десктоп... Недавно случилось забавное. Откопал откуда-то старый ноут 2007 года выпуска с 512Mb RAM , процессором Intel Core 2 Duo T2400 и интегрированной графикой Intel. Задачей ноутбука было проигрывать видео с ютюба и стрим с телеканалов. Сначала поставил убунту 14.04. Все бы хорошо, только видео во флеше с дикими лагами на любом разрешении. Копался в форумах, пробовал менять настройки всякие - не помогло. Что в firefox, что в хроме - одинаково. CPU ничем другим не нагружал, а флеш его грузил далеко не на 100%. Память свободная была, винт молчит, то есть, это не из-за своппинга. Снес убунту, поставил PCBSD 10 (правда, на UFS, не на ZFS, я же не маньяк ставить ZFS на комп с 512Мб ОЗУ), про который думал сначала, что он не подхватит видеокарту. Подхватил, и, что самое интересное, видео от флэш-плейера - без лагов. Вот объясни мне, 294ый, как такое возможно - флеш-плейер для линукса в PCBSD работает лучше, чем в самом линуксе?
> А какой-нибудь eCOS тоже нужно разрабатывать, имея на рабочей станции eCOS? User294,
> годы идут, а ты все никак не поумнеешь.А какой-нибудь eCOS никто и не сватает как систему общего назначения. Он нынче используется в основном как boot loader :-) для пингвина (RedBoot-ом это нечто называется).
> Кстати сказать, про десктоп... Недавно случилось забавное. Откопал откуда-то
> старый ноут 2007 года выпуска с 512Mb RAM ,Ну вот все success story почему-то про древнее окаменелое гомно мамонта. Чувак, на дворе 2014 год! И у моего cubieboard (размером чуть больше кредитки) - памяти на борту в 2 раза больше. И хардварный акселератор декодирования видео. То что он от ноутбучной батареи сможет работать, наверное, неделю - вообще лол. Поэтому у меня нынче другие радости: китайский AXP20x замайнлайнили.
> убунту, поставил PCBSD 10 (правда, на UFS, не на ZFS, я
> же не маньяк ставить ZFS на комп с 512Мб ОЗУ),Ну да, древнему гомну - и система под стать. С тормозной безблагодатной ФСиной. А как захочешь современное железо использовать, тут и оказывается что бзды в пролете как мухи в самолете.
> про который думал сначала, что он не подхватит видеокарту.
Ну знаешь, не подхватить видеокарту семилетней (!!!) давности - это был бы номер. В смысле это означало бы 100% полную дохлоту проекта, как минимум в плане графики. А там вроде какие-то трепыхания все-таки есть.
> Подхватил, и, что самое интересное, видео от флэш-плейера - без лагов.
> Вот объясни мне, 294ый, как такое возможно - флеш-плейер для линукса
> в PCBSD работает лучше, чем в самом линуксе?Понятия не имею. И даже не собираюсь узнавать. Почему?
1) Мне не интересно железо 7-летней давности. То железо которое мне интересно - в пингвине обычно работает как минимум "неплохо" или хотя-бы имеются ощутимые усилия по приведению в нормальное состояние. А если меня кусает баг - я иду и колочу его в багтрекер, для информирования причастных. И как-то так обычно получается что в целом все довольно прилично работает.
2) Я не пользуюсь флешом. Потому что не ретард. Ютуб уже наверное как год или два прекрасно работает вообще совсем без флеша. Разбираться в глюках этой сpaни, писаной криворукими индусскими проприерасами из адобы мне совершенно не с руки.
3) Как ты понимаешь, я не могу произвести ремотное профилирование и трублешутинг. А вот более другие юзкейсы я и отпрофайлить могу. Но - интересные мне. Это уж точно не про кусок гуано от адобы на окаменелом оборудовании 2007 года. Потому что такие начинания по моей классификации как минимум "не доставляют". Я не мусорщик чтобы копаться в технологических отбросах адобы и древнем оборудовании. Кому надо - тот пусть это гуано и трублешутит.И вообще у меня немного другие развлечения. Вот например открытый графический стек. Он считает 260Мхешей на R9 270 (bfgminer/sha256 - benchmark mode). Here and now. Неплохо для начала. Приятно видеть как открытый стек крепнет. И вот уже может запустить довольно тяжелую OpenCL программу без отвалов башки. Багов там, конечно, немеряно, но все то что меня кусать посмеет я таки постепенно отловлю, сам понимаешь. Вот какие-то такие развлечения мне нравятся. А в окаменелом железе 2007 года и адобовском глюкалове вы там сами копайтесь.
Пользуюсь.
Спасибо парням!
Особенно выручает тогда, когда случается вытаскивать данные из снятых HDD с файлопомоища и сданных на архивное хранение...
а как zfs уживается с glusterfs или модным docker?