The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Первый стабильный выпуск BTIER, блочного устройства для агрегирования накопителей в Linux

27.05.2013 10:28

Представлен первый стабильный релиз проекта BTIER 1.0.0, предназначенного для формирования многоуровневых блочных устройств, состоящих из нескольких разнотипных устройств небольшого размера. Код системы отмечен как стабильный и прошедший тестирование в промышленном использовании, в том числе в достаточно сложных конфигурациях, в которых используются сетевые разделы DRDB и работают приложения Oracle. BTIER оформлен в виде модуля для ядра Linux, который может быть собран для ядер, начиная с выпуска 2.6.32. Изначально проект развивался под именем TIER, но был переименован в BTIER для того чтобы упростить выборку связанной с проектом информации через поисковые системы. Исходные тексты BTIER распространяется под лицензией GPL.

За счёт оптимального разнесения блоков по дискам и использования техники активного кэширования данных в ОЗУ раздел на базе BTIER позволяет заметно поднять производительность сводного раздела. Например, при тестировании BTIER-раздела, созданного на базе SSD-накопителя STEC Zeus и 5 SAS НЖМД, и экспортируемого через iSCSI (SCST), была продемонстрирована способность выполнения заметно большего числа операций в секунду, по сравнению с системой кэширования на SSD-накопителях BCache.

Использование BTIER позволяет достигнуть более высокой производительности по сравнению с другими методами ускорения доступа к данным, использующими SSD-накопители, благодаря применению техники кэширования в оперативной памяти, ранее реализованной в RAM-диске EPRD. При распределении данных по дискам TIER учитывает статистику доступа к уже размещённым данным, например, принимает во внимание то, когда данные использовались последний раз и как часто они запрашиваются. При наличии разных типов накопителей в пуле, отличающихся скоростными характеристиками, наиболее востребованные данные будут вытеснены на более быстрые накопители, такие как SSD или SAS НЖМД, а редко используемые данные будут размещены на медленных дисках.

В итоге, BTIER позволяет значительно сэкономить, используя SSD только для действительно востребованных данных, при том, что общая ёмкость всего быстрого хранилища в BTIER составляет сумму из всех подключенных устройств хранения. Например, близкий аналог flashcache может поддерживать отдельный кэш из SSD-накопителей поверх традиционных дисков, дублируя данные, в то время как BTIER максимально эффективно использует доступное пространство. Кроме производительности, от других систем виртуального слияния хранилищ BTIER отличается поддержкой автоматической миграции данных между накопителями и обеспечением "умной" балансировки размещения блоков данных на накопителях в зависимости от характера нагрузки.

  1. Главная ссылка к новости (http://www.lessfs.com/wordpres...)
  2. OpenNews: EPRD - реализация RAM-диска, обеспечивающего постоянное хранение данных
  3. OpenNews: Facebook открыл модуль Flashcache для организации кэширования на SSD-накопителях
  4. OpenNews: Система кэширования на SSD-накопителях BCache претендует на включение в ядро Linux
  5. OpenNews: Выпущен первый кандидат в релизы ядра Linux 3.10 (3.10-rc1)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37023-btier
Ключевые слова: btier, teir, kernel, module, cache, speed, disk, ssd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, виндотролль (ok), 11:41, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Вот это, я понимаю! Не то что всякие там фюжндрайвы и турбобусты (или как там в винде называется кеширование дллок).
    Да еще и под GPLv3!
     
     
  • 2.4, Andrey Mitrofanov (?), 11:55, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Да еще и под GPLv3!

    Путаешь с lessfs.

    btier-1.0.0.tar.gz лежит COPYING =GPLv2, в "документации" лицензия не поминается, в исходнике модуля, в _одном файле из _7_:

    * Partly based up-on sbd and the loop driver.
    * Redistributable under the terms of the GNU GPL.

     
     
  • 3.12, виндотролль (ok), 12:12, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пардон, зашел сюда http://www.lessfs.com/wordpress/, увидел GPLv3 и обрадовался... Спасибо.

    Да все-равно круто же.

     
     
  • 4.19, ананим (?), 12:24, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже круче — значит можно ожидать в ваниле, то биш "изкаропки".
    Не удивлюсь что именно поэтому и гпл2.
     
  • 2.6, linux must _RIP_ (?), 11:57, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –13 +/
    очередной троль - который не потрудился посмотреть исходники. GPL v2 таки более популярна и она использована.
     
     
  • 3.13, виндотролль (ok), 12:14, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > очередной троль - который не потрудился посмотреть исходники.

    Спасибо, что прочитали мой ник. А Вы тире не к месту употребили ;)

     
     
  • 4.20, ананим (?), 12:25, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так у него как? Если ворд не подчёркивает, значит правильно.
     
     
  • 5.31, linux must _RIP_ (?), 13:17, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –8 +/
    хреновый из тебя наблюдатель ;-)
     
     
  • 6.35, ананим (?), 13:45, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С чего ты взял что я за хренами наблюдаю? :D
     
     
  • 7.48, Аноним (-), 17:02, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > С чего ты взял что я за хренами наблюдаю? :D

    Судит всех по себе, видимо.

     
  • 3.60, Аноним (-), 19:21, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > очередной троль

    Ты настолько лузер, что даже слово "тролль" не можешь правильно написать. Позор!

     

  • 1.2, Аноним (-), 11:46, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    наконец то, что нужно!!!  годнота!!!
     
  • 1.3, cmp (??), 11:46, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Дык линукс же и так кеширует весь обмен с фс в ОЗУ, то есть, хошь ускориться добей оперативы; сервера нагруженные, так ведь там и железо соответстующее, в крайнем случае есть своп, который как раз и можно держать на ссд или сас, если данные в оперативу совсем не лезут, в чем профит?
     
     
  • 2.7, Andrey Mitrofanov (?), 11:59, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Дык линукс же и так кеширует весь обмен с фс в ОЗУ,
    > то есть, хошь ускориться добей оперативы;

    Ну, как бы тех, кто пишет и использует БД интересует момент окончания _записи на ...[ммм, как это есть по-русски]... non-volatile носитель.

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

    :*)))

     
     
  • 3.9, Andrey Mitrofanov (?), 12:03, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > кто пишет и использует БД интересует момент окончания _записи на

    Гм. Поправочка "ФС и БД".

     
  • 3.18, linux must _RIP_ (?), 12:23, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    я бы сказал - на persistent storage. особенно в плане комита транзакций. Поэтому в linux был в свое время (может и даже сейчас) смешной баг у dm_multipath - когда один из каналов более быстрый и более новые транзакции комитились раньше старых, что приводило к неработоспособности барьеров внутри FS.
     
     
  • 4.22, ананим (?), 12:34, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Дык у всех мультипасов такой "баг". Они как бэ нагрузку и не предназначены балансировать.
    Пихание разнотипных носителей по такой схеме сродни забиванию гвоздей буратинами.
    Тоже было (на личном опыте своими глазами видел) и в соляре, а в винде (2000) вообще отвалившийся девайс только минут через 20 "обнаруживался" пропавшим. И все транзакции за это время как в /dev/null ушли.
     
     
  • 5.32, linux must _RIP_ (?), 13:18, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Дык у всех мультипасов такой "баг". Они как бэ нагрузку и не
    > предназначены балансировать.
    > Пихание разнотипных носителей по такой схеме сродни забиванию гвоздей буратинами.
    > Тоже было (на личном опыте своими глазами видел) и в соляре, а
    > в винде (2000) вообще отвалившийся девайс только минут через 20 "обнаруживался"
    > пропавшим. И все транзакции за это время как в /dev/null ушли.

    Правильные multi path реализуют правильные барьеры :) да да - есть командочка такая в bio уровне.
    не правильные - убивают FS в хлам. Вывод делать вам :)

     
     
  • 6.37, ананим (?), 13:50, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мультипас не реализуют барьеры. Вообще. :D
     
  • 6.46, Аноним (-), 16:59, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Правильные multi path реализуют правильные барьеры

    Это где такие? Ну, кроме вашего воображения.

     
  • 2.15, Аноним (-), 12:18, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > если данные в оперативу совсем не лезут

    то нужно не городить свопы а разгрузить телегу

     
  • 2.16, ананим (?), 12:20, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    1. Объединение разнотипных, разноскоростных, разноразмерных (и тд) устройств в одно логическое.
    2. Никакой кэшЪ не поможет от синк. Если процессу нужно точно знать, что данные на диске, то будет иовэйт по-любому. К примеру в оракле (по-мимо транзакций и тд) каждые 3 секунды чекпоинт, скидывает "грязные" блоки на диск.

    Зыж
    Вопрос по сабжу — как с загрузкой с таких разделов? И когда будет в ванниле?

     
     
  • 3.26, pavlinux (ok), 12:53, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Если процессу нужно точно знать, что данные на диске, то будет иовэйт по-любому.

    Процессу можно сказать, что данные есть, "- а где  и как - тя нипёт!".

     
     
  • 4.36, ананим (?), 13:49, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Можно.
    Но никто (в зравом уме) этого им не говорит.
    Особенно на рсубд в режиме 24*7*365.
     
  • 4.61, Аноним (-), 19:24, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Процессу можно сказать, что данные есть, "- а где  и как - тя нипёт!".

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

     
  • 3.66, Аноним (-), 22:02, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    в смысле как? initrd
     

  • 1.5, Аноним (-), 11:56, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    еще бы совместно с  EPRD  заюзать, будет просто супер!
     
     
  • 2.14, Аноним (-), 12:15, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем? Задачи разные. Никто не мешает сделать EPRD поверх.
     
  • 2.25, Аноним (-), 12:52, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > еще бы совместно с  EPRD  заюзать, будет просто супер!

    А разве EPRD не блочное устройство?
    Или BTIER блочные устройства не поддерживает?

     
  • 2.65, saNdro (?), 21:43, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Так никто и не мешает их юзать параллельно. Можешь не сомневаться. ERPD был убран из TIER автором уже вроцессе развития, что бы не дублировать код проекта. Автор, кстати, у них один и тот же.
     

  • 1.8, Аноним (-), 12:02, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    DRBD
     
     
  • 2.10, Andrey Mitrofanov (?), 12:04, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > DRBD

    Семнадцать!

     
  • 2.23, Аноним (-), 12:35, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Асфальт
     
     
  • 3.29, Нанобот (?), 12:58, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не согласен
     
     
  • 4.45, Аноним (-), 16:58, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Неожиданный ход.
     
     
  • 5.82, anoncppagli (?), 11:43, 29/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Макароны
     
  • 2.24, Аноним (-), 12:43, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Distributed Replicated Block Device

    для тех кто не понял, это было на "сетевые разделы DRDB"

     

  • 1.11, Аноним (-), 12:07, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Аналог технологии FAST (Fully Automated Storage Tiering).
    Хорошо.
     
  • 1.17, pavlinux (ok), 12:22, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    НоtSwap и Hot Spare надо, в виде утилиты хотя бы.
     
     
  • 2.49, Moomintroll (ok), 17:11, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Hot Spare не спасёт ввиду отсутствия избыточности. Если хоть один из носителей вылетит, то менять его будет уже поздно - данные потеряны. А вот Ноt Swap таки поможет, если за S.M.A.R.T.ом следить и вовремя диски менять.
     

  • 1.21, NikolayV81 (?), 12:27, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD, а то определить какие данные потерялись при вылете SSD будет проблематично, хотя вероятнее всего самые нужные ;)
     
     
  • 2.27, pavlinux (ok), 12:57, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
    > а то определить какие данные потерялись при вылете SSD будет проблематично,
    > хотя вероятнее всего самые нужные ;)

    можно замутить RAID 1 из BTIER дисков =-o

     
     
  • 3.43, Аноним (-), 15:44, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
    >> а то определить какие данные потерялись при вылете SSD будет проблематично,
    >> хотя вероятнее всего самые нужные ;)
    > можно замутить RAID 1 из BTIER дисков =-o

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

     
     
  • 4.57, проходил мимо (?), 18:49, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ssd перешел в ro,как его заменить? это raid5 из 5-ти hdd+ssd, а tier 1 = raid5 из 5 hdd + tier 2 из ssd. В самом деле, сценарий восстановления тут интересен - останов всей конструкции на замену и раздельное зеркалирование ssd, а затем сбор всей конструкции заново -  весьма слабый и непромышленный вариант.
     
  • 4.68, pavlinux (ok), 22:24, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Данные не теряются. Если не может записать на SSD, пишет на другой диск.

    А куда они денутся? BTIER - по сути, это RAID0 в режиме FIFO,
    где верх кучи это самый быстрый диск.

     
  • 2.28, Аноним (-), 12:57, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
    > а то определить какие данные потерялись при вылете SSD будет проблематично,
    > хотя вероятнее всего самые нужные ;)

    Интересная штука, используя N x RAID1 из SSD мы поднимаем отказоустойчивость от вероятного "протирания до дырки" грубо в N раз, а применяя на них N x RAID0 мы увеличиваем ресурс в N раз, тем самым снижая эту вероятность.

     
     
  • 3.34, NikolayV81 (?), 13:33, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
    >> а то определить какие данные потерялись при вылете SSD будет проблематично,
    >> хотя вероятнее всего самые нужные ;)
    > Интересная штука, используя N x RAID1 из SSD мы поднимаем отказоустойчивость от
    > вероятного "протирания до дырки" грубо в N раз, а применяя на
    > них N x RAID0 мы увеличиваем ресурс в N раз, тем
    > самым снижая эту вероятность.

    если исключить вроде как не подтверждённую проблему "SSD зеркалу иногда имеет особенность умирать целиком", то таки в случае зеркало будет некоторое время для замены ;) ...


     
     
  • 4.38, Аноним (-), 14:38, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В зеркале износ одинаковый для всех компонент, общий ресурс равен наибольшему из устройств, следовательно оно практически не защищает от износа. В страйпе общий ресурс равен наименьшему из компонент умноженному на их количество.
    Насчет времени для замены, лучше чтобы его никогда не случилось.
     
     
  • 5.39, NikolayV81 (?), 14:44, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В зеркале износ одинаковый для всех компонент, общий ресурс равен наибольшему из
    > устройств, следовательно оно практически не защищает от износа. В страйпе общий
    > ресурс равен наименьшему из компонент умноженному на их количество.
    > Насчет времени для замены, лучше чтобы его никогда не случилось.

    И к чему это? на серверах всегда выходили из строя диски, и весь смысл зеркалирования, и его "развитий" в том что бы в случае выхода из строя ( который в дата центрах является плановым событием ) в сохранении данных...
    > ресурс равен наименьшему из компонент умноженному на их количество.

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

     
     
  • 6.40, Аноним (-), 15:06, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если не говорить об отказах электроники, а только об износе механическом (HDD) и электронном (SSD), то картина следующая. Чем больше у нас в массиве HDD тем выше вероятность отказа. В случае механики она еще и менее предсказуема. А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс. Разницу видно?
    Ну и RAID10 никто не отменял.

    > ресурс человека

    Потеря одной клетки не влечет за собой гибель организма.
    Если организм не одноклеточный ;)

     
     
  • 7.41, NikolayV81 (?), 15:11, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс.

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

     
     
  • 8.44, Аноним (-), 15:52, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала подумайте, с чего бы это ресурс в SSD измеряют в циклах записи а то и... текст свёрнут, показать
     
     
  • 9.53, NikolayV81 (?), 17:38, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    физически у вас отказ перезаписи ячейки, на практике развал фс ячейка оказалос... текст свёрнут, показать
     
     
  • 10.59, Аноним (-), 19:15, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не совсем понятно, что вы хотите доказать И кому Я выразил свою точку зрения н... текст свёрнут, показать
     
     
  • 11.70, nikolayv81 (?), 23:00, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в общем начали с этого, возможно по пути потерял где то ход мысли ... текст свёрнут, показать
     
  • 10.67, Аноним (-), 22:10, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы хоть почитай не про устройство фс и в каких фс как хранят данные и как работа... текст свёрнут, показать
     
     
  • 11.83, Аноним (-), 15:15, 29/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Он о метаданных, упырь ... текст свёрнут, показать
     
  • 2.42, Аноним (-), 15:38, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В LSI есть CacheCade. И помнится на семинаре представителю LSI задавали вопрос: - "А что происходит и как обрабатывается ситуация, когда SSD умирает?"

    Так вот он ответил, что если SSD умирает из-за ресурса, то чтение сохраняется все равно. Т.е. нельзя записать новые данные, а старые прочитать можно. Т.о. ничего страшного не происходит.
    Если умирает электроника, то конечно все плохо. Но вылет электроники крайне редок, и теоретически после починки данные возможно вытащить все равно.

     
     
  • 3.58, проходил мимо (?), 18:52, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Так вот он ответил, что если SSD умирает из-за ресурса, то чтение
    > сохраняется все равно. Т.е. нельзя записать новые данные, а старые прочитать
    > можно. Т.о. ничего страшного не происходит.
    > Если умирает электроника, то конечно все плохо. Но вылет электроники крайне редок,
    > и теоретически после починки данные возможно вытащить все равно.

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

     

  • 1.30, Анонимко (?), 13:07, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Они изобрели FreeBSD-шный GEOM для Linux и добавили местечковых костылей, вот и вся новость.
     
     
  • 2.33, Аноним (-), 13:30, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Толстопуз, окстись. GEOM тут ни с одной из шести сторон.
     
  • 2.47, Аноним (-), 17:01, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Они изобрели FreeBSD-шный GEOM для Linux и добавили местечковых костылей, вот и вся новость.

    Ликвидируем безграмотность среди школьников: "FreeBSD-шный GEOM" - это просто копипаста с линуксового device mapper.

    Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.

     
     
  • 3.50, Аноним (-), 17:21, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А можно еще сказать, что возможности ZFS, имеющиеся во FreeBSD, в линуксе реализуемы только костылями в виде BTIER и Btrfs :)
     
     
  • 4.51, Аноним (-), 17:33, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А можно еще сказать, что возможности ZFS, имеющиеся во FreeBSD, в линуксе реализуемы только костылями в виде BTIER и Btrfs :)

    Или наоборот: возможности ZFS и Btrfs, имеющиеся в линуксе, во FreeBSD реализуются только костылями в виде ZFS.

     
     
  • 5.52, Аноним (-), 17:34, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже так: возможности ZFS, Btrfs и BTIER.
     
  • 5.54, Аноним (-), 17:39, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > возможности ZFS..., имеющиеся в линуксе

    Да, несчастные бсдешники уже и забыли, что с появлением zfsonlinux количество преимуществ freebsd перед linux вернулось на исторически сложившийся уровень (0).

     
     
  • 6.75, Школьник (ok), 10:36, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пока zfsonlinux не появится в ядре, оно будет просто детской игрушкой для энтузиастов. А в ядре оно не появится никогда.

    ЗЫ Ох, какие у нас линуксолюбивые модераторы пошли, трут неудобные комментарии на раз. А чего бы не стереть тогда уж и тот комментарий, на который я отвечаю? Религия мешает? Как можно любить free software и не любить свободу выражения мнения?

     
     
  • 7.78, ананим (?), 21:04, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Какая религия? Видел я твой коммент, смесь спеси, хамства и невежества.
    Ау? Это ты бсд имел ввиду, говоря про энтерпрайз? Ха.
    Патчинг ядра и смена форматов вообще шедевр. Ау, у zfsonlinux тотже формат и версия, что и в бсд. Какой нафиг патчинг?
    Такое ощущение, что виндовые вирусы стали поражать уже и вантузятников.
     
  • 3.62, Аноним (-), 19:24, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.

    В ZFS это просто банальный кэш. Ни о каком tiering'е там сегодня речи быть не может.

     
     
  • 4.84, Аноним (-), 15:16, 29/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.
    > В ZFS это просто банальный кэш. Ни о каком tiering'е там сегодня
    > речи быть не может.

    Потому что он там в пень не уперся. Она чутка для других задач, нежели самодельное гогно.

     
  • 3.77, Кирилл (??), 16:09, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, в ZFS ничего похоже нет.
     

  • 1.55, Кирилл (??), 17:56, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это типа FusionDrive в Mac OS X?
     
  • 1.64, Аноним (64), 21:25, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В начальном посте сказано что данные кэшируются в озу. А чего произойдет если будет падение ноды по питанию ? Большие дедьки типа нетаппа гонят данные через nvram кэш, а тут через озу.
     
     
  • 2.69, pavlinux (ok), 22:28, 27/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А чего произойдет если будет падение ноды по питанию ?

    закупка новых бесперебойников

     
     
  • 3.71, Аноним (64), 01:02, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    LOL. Ну это обойтись малой кровью. Конечно же имеется ввиду если нода вылетела в силу каких-то причин.
     
     
  • 4.86, pavlinux (ok), 03:26, 31/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > LOL. Ну это обойтись малой кровью. Конечно же имеется ввиду если нода
    > вылетела в силу каких-то причин.

    Чо, чо... только своевременные бэкапы, переодические инкрементальные бэкапы.
    Такие вещи продумывают ещё до закупки оборудования. Критически важные данные
    хранят на соседнем RAID61. Если работаш с БД - репликация, с файлам - сетевое зеркалирование/синхронизация.

     
  • 2.72, Аноним (-), 01:42, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А чего произойдет если будет падение ноды по питанию

    не закоммитить изменения на диск

     

  • 1.73, анонимм (?), 09:29, 28/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не попахивает ли тут Venti?
     
  • 1.74, docent (??), 10:04, 28/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Например, близкий аналог flashcache может поддерживать отдельный кэш из SSD-накопителей поверх традиционных дисков, дублируя данные, в то время как BTIER максимально эффективно использует доступное пространство.

    А эта эффективность нужна?
    Например, размер СХД 12ТБ, для оптимизации работы достаточно SSD скажем на 200ГБ.
    Т.о. получаем "эффективность" 200/12000=1.6%
    Но для надежности придется использовать 2 зазеркаленых диска SSD.
    Мне кажется, что использовать SSD как кэш было бы более эффективно и надежно.

     
     
  • 2.79, ананим (?), 21:10, 28/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нужна.
    Во-первых, реализации аля кэш уже есть. Пользуйтесь.
    Во-вторых, вот есть у меня ноут. Двд сменил на ссд. Вот сабж более чем к месту тут.
    В-третьих, в случае кэша в/в всё равно дублируется. Что может быть критично. Графики выше.
     

  • 1.76, amorphine (?), 15:42, 28/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну все. Теперь линукс точно готов для десктопа
     
     
  • 2.80, Аноним (-), 06:33, 29/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Дааа  ... теперь походу десктоп не готов для линукса :)
     

  • 1.81, anoncppagli (?), 11:41, 29/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А можно простыми словами для чего оно нужно?
     
     
  • 2.85, Кирилл (??), 12:45, 30/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вот есть у вас очень быстрый ссд, но он мелкий и относительно дорогой, и есть очень большой и дешёвый, но медленный жёсткий диск. Вы можете сами раскладывать то, что по-вашему, требует быстрого чтения и редко изменяется на быстрый ссд, а жёсткий диск использовать для данных, которые не так критичны к скорости загрузки. Но как определить что куда класть, да и следить за этим нужно. В общем, слишком много мороки. А эта технология позволяет залепить из ссд и жёсткого диска один раздел, а потом сама ведёт статистку использования и решает какие файлы (или блоки) на какой физический носитель пихать. За счёт этого конечный пользователь получает и высокую скорость загрузки и преимущества большого и дешёвого носителя.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру