Кент Оверстрит (Kent Overstreet) объявил (https://lkml.org/lkml/2013/1/14/448) в списке рассылки разработчиков ядра Linux о готовности реализации системы кэширования блочных устройств на SSD-накопителях BCache (http://bcache.evilpiepirate.org/) для интеграции в ядро Linux. Первые реализации Bcache были представлены ещё в 2010 году и развивались обособленно, теперь все требования по оформлению кода выполнены, а ранее мешавшие интеграции кода ограничения в уровне блочных устройств Linux обойдены, и проект в скором времени может быть принят в основное ядро. Проект отмечается как стабильный и достаточно давно используемый на нескольких крупных серверах в режиме промышленной эксплуатации.
Bcache позволяет организовать кэширование доступа к медленным жестким дискам на быстрых SSD-накопителях, при этом кэширование ведётся на уровне блочного устройства, что позволяет ускорить доступ к накопителю независимо от используемых на нём файловых систем. Один SSD-накопитель может использоваться для кэширования нескольких различных блочных устройств. Блочное устройство может быть на лету прикреплено к кэшу и отключено от него, без размонтирования и временно остановки работы.
Поддерживается два режима кэширования: сквозное кэширование (writethrough), при котором записываемые данные сразу сохраняются на исходном накопителе и оседают в кэше только для ускорения операций чтения; режим отложенной записи (writeback) при котором данные записываются на исходный носитель не сразу, что позволяет обеспечить ускорение операций записи но может привести к потере блоков данных при сбое SSD-накопителя. Дополнительно поддерживается, но отключен по умолчанию, режим readahead, при котором кэш наполняется не только при записи, но и при операциях чтения.
Из особенностей Bcache также можно отметить достаточно продвинутую логику кэширвоания, например, Bcache выявляет и не сохраняет в кэше последовательные обращения к большому объему данных, кэшируя только операции случайного чтения и записи. Bcache пытается оптимально использовать характеристики SSD-накопителей, учитывая ограниченный ресурс по записи данных и преобразуя случайные операции записи в последовательное заполнение накопителя. При writeback-кэшировании, при сбросе данных на диск, данные группируются с учётом минимизации перемещения головок диска. Универсальный подход к кэшированию делает Bcache подходящим решением как для серверных систем и крупных массивов хранения, так и для рабочих станций и встраиваемых систем.Большое внимание также уделяется надёжности хранения данных и обработке внештатных ситуаций, таких как внезапное выключение питания. BCache контролирует такие ситуации и после возобновления работы дописывает на жесткий диск данные, которые остались в кэше но не были записаны на диск в момент сбоя при активном режиме writeback. BCache возвращает статус успешной операции только после того как данные сохранены на постоянном носителе (на SSD при использовании режима writeback).
URL: https://lkml.org/lkml/2013/1/14/448
Новость: http://www.opennet.me/opennews/art.shtml?num=35849
> - выявляет и не сохраняет в кэше последовательные обращения к большому объему данных кэшируя только операции случайного чтения и записи.
> - оптимально использовать характеристики SSD-накопителей, учитывая ограниченный ресурс по записи данных.
> - преобразуя случайные операции записи в последовательное заполнение накопителя.
> - данные группируются с учётом минимизации перемещения головок диска.У меня такое ощущение, что он переделал TAR (Tape ARchiver) или
эмулятор контроллера ленточного накопителя :)
> У меня такое ощущение, что он переделал TARЧто ты такое куришь, Павлин? Мне всегда было интересно - что надо скурить чтобы такую фигню с таким упоением нести в массы :)
Я-то что, а вот писать х...ню, о том, что написали ху..ню, не указывая в чем, вот это верх дебилизма.
Вы оба правы.
Что-то мне это напоминает CacheCade от LSI и MaxCache от Adaptec.
> Что-то мне это напоминает CacheCade от LSI и MaxCache от Adaptec.Ну вот, хоть один вкурил.
> поддерживается, но отключен по умолчанию, режим readahead, при котором кэш наполняется не только при записи, но и при операциях чтенияа разве это не режим с самой высокой производительностью?
почему он отключен?
Тоже не понял это решение.
Ведь если кешировать то, что читается, наиболее востребованные данные будут на SSD.
отвечу самому себе:
возможно, если кэшировать, всё, что читается, то при просмотре видео будет быстро умирать SSD
там же написано, последовательные чтения/запись не кешируются
Возможно, просто берегут ресурс SSD. Если я правильно понял логику работы кеша, то при readahead режиме количество данных, сливаемых в SSD, растет в разы, причем далеко не все из этих данных будут впоследствии востребованы (особенно, если учесть строчку о том, что bcache избегает последовательного чтения).UPD. Опередили :)
И сейчас мы придем - ВНИМАНИЕ! - ТАДАААААА!! - к ARC. Всеми з@блеванный и который тут только ленивый не пинал - ARC! С его двухуровневым кэшированием, в т.ч. SSD.NIH во всей красе, ляпотаааааааааааа. Ну просто чудо как хороши эти пiнгвин@иды!
"ви таки нэ поняли"
и где здесь отрезанный от ОЗУ кусок? Вижу что-то подобное L2ARC+ZIL (точнее общий настраиваемый l2 кеш) а вот ARC в ОЗУ не вижу...
Боюсь, это ви не поняли. L2ARC - Это не часть ARC? Не? Который состоит из L1 и L2 в текущей версии? Будем иезуитствовать дальше или по существу есть возражения?
покажите мне подсистему в Linux-е, которая будет ARC (без приставки L2 - кеш чтения первого уровня), на который все "наезжали" в ZFS - и разберемся в чем отличие ее от ARC.bcache - повторюсь это *грубо* аналог L2ARC (кеш чтения второго уровня) + ZIL (кеш записи).
> Боюсь, это ви не поняли. L2ARC - Это не часть ARC? Не?L2ARC не часть ARC (который целиком в памяти и динамически изменяет свой размер), а отдельное виртуальное устройство ZFS пула (cache device), служащее промежуточным слоем кэширования данных при чтении с дисков между основной памятью и дисками. Не поддерживает объединения физических устройств кэширования в mirror и raid-z.
ZIL, кэш на запись — это виртуальное устройство ZFS пула (log device), призваное обеспечить асинхронную запись данных в пул. Поддерживает объединение физических устройств кэширования в mirror.
> Который состоит из L1 и L2 в текущей версии? Будем иезуитствовать
> дальше или по существу есть возражения?
На ARC злые патенты, его нельзя просто так взять и реализовать. Что еще остается делать, кроме как придумывать альтернативу? Смешные вы, вначале запатентуете вусмерть, а потом пытаетесь пиарить. Спасибо, лучше изобрести что похуже или иначе, но не лезть в патентное болото.
насколько я понимаю вопрос не в пиаре - вопрос в том что тут кричали "не нужно" "отстой - надо выкинуть",
а сами тихонько пилили аналог.PS, часть патентов на ARC принадлежит IBM - но это же лучший друг Linux ?
Ну что ты как маленький, кричали одни, а пилили другие
> Что еще остается делать, кроме как придумывать альтернативу?Лицензировать патенты, не?
EPIC FAIL! ARC в ZFS - это отдельный системонезависимый кэш в памяти, который нормально системой не управляется. В данном случае имеем аналог L2ARC, не более.
> ARC в ZFS - это отдельный системонезависимый кэш в памяти,
> который нормально системой не управляется.А чем он управлятся, интересно, как не системой. Может святым духом? Из Астрала?! :))
> А чем он управлятся, интересно, как не системой. Может святым духом? Из
> Астрала?! :))Управляется он только внутри ZFS, и к ОС имеет примерно такое же отношение, как и юзерспейс.
> И сейчас мы придем - ВНИМАНИЕ! - ТАДАААААА!! - к ARC.Не ARC а чему-то отдаленно похожему L2ARC. А вот этот ваш ARC который память жрет и системе ее не может отдать при необходимости - вот вы таким и пользуйтесь.
>> И сейчас мы придем - ВНИМАНИЕ! - ТАДАААААА!! - к ARC.
> Не ARC а чему-то отдаленно похожему L2ARC. А вот этот ваш ARC
> который память жрет и системе ее не может отдать при необходимости
> - вот вы таким и пользуйтесь.Не знал, что в Linux с ZFS ARC-кэш память жрёт и не отдаёт. Теперь буду знать.
> Не знал, что в Linux с ZFS ARC-кэш память жрёт и не
> отдаёт. Теперь буду знать.И в Linux, и в BSD, и в Solaris... В силу убогого дизайна.
>> Не знал, что в Linux с ZFS ARC-кэш память жрёт и не
>> отдаёт. Теперь буду знать.
> И в Linux, и в BSD, и в Solaris...Интересно, а где ты об этом прочитал?
> Интересно, а где ты об этом прочитал?У санок/оракла. Про архитектуру ZFS + Evil Tuning Guide. А щито, собственно?
>> Интересно, а где ты об этом прочитал?
> У санок/оракла. Про архитектуру ZFS + Evil Tuning Guide. А щито, собственно?ARC — это адаптивный кэш. Изменяет свой размер как в сторону увеличения (когда идёт кэширование), так и в сторону уменьшения (когда запускаются новые приложения и им нужна память).
Начинаю копировать большой файл, размер которого больше, чем размер оперативной памяти:
% top
last pid: 8469; load averages: 0.14, 0.77, 1.06 up 0+03:07:37 23:04:44
61 processes: 1 running, 60 sleeping
CPU: 1.8% user, 0.0% nice, 1.7% system, 0.0% interrupt, 96.6% idle
Mem: 844M Active, 108M Inact, 5435M Wired, 4420K Cache, 1016M Free
ARC: 4420M Total, 2160M MRU, 1741M MFU, 24M Anon, 71M Header, 424M Other
Swap: 1024M Total, 1024M Free% top
last pid: 8473; load averages: 0.18, 0.59, 0.94 up 0+03:09:49 23:06:56
63 processes: 1 running, 62 sleeping
CPU: 3.1% user, 0.0% nice, 0.7% system, 0.3% interrupt, 95.9% idle
Mem: 404M Active, 296M Inact, 6131M Wired, 187M Cache, 389M Free
ARC: 5243M Total, 2920M MRU, 1818M MFU, 14M Anon, 73M Header, 417M Other
Swap: 1024M Total, 1024M FreeЗапускаю приложения: RSSOwl, Deluge, Firefox, Thunderbird:
% top
last pid: 8541; load averages: 1.12, 0.69, 0.91 up 0+03:12:23 23:09:30
64 processes: 1 running, 63 sleeping
CPU: 8.1% user, 0.0% nice, 2.2% system, 0.0% interrupt, 89.6% idle
Mem: 487M Active, 540M Inact, 6004M Wired, 644K Cache, 376M Free
ARC: 5122M Total, 2812M MRU, 1818M MFU, 592K Anon, 76M Header, 416M Other
Swap: 1024M Total, 1024M Free% top
last pid: 8545; load averages: 0.60, 0.61, 0.85 up 0+03:13:53 23:11:00
65 processes: 1 running, 64 sleeping
CPU: 5.7% user, 0.0% nice, 2.8% system, 0.0% interrupt, 91.5% idle
Mem: 487M Active, 521M Inact, 6010M Wired, 644K Cache, 388M Free
ARC: 5123M Total, 2686M MRU, 1920M MFU, 32M Anon, 71M Header, 414M Other
Swap: 1024M Total, 1024M Free% top
last pid: 8565; load averages: 0.56, 0.59, 0.81 up 0+03:15:43 23:12:50
66 processes: 1 running, 65 sleeping
CPU: 5.0% user, 0.0% nice, 1.7% system, 0.4% interrupt, 92.9% idle
Mem: 603M Active, 439M Inact, 5970M Wired, 1140K Cache, 394M Free
ARC: 5075M Total, 2421M MRU, 2170M MFU, 8416K Anon, 68M Header, 408M Other
Swap: 1024M Total, 1024M Free
Конец копирования большого файла:% top
last pid: 8578; load averages: 0.57, 0.54, 0.68 up 0+03:23:22 23:20:29
67 processes: 1 running, 66 sleeping
CPU: 10.0% user, 0.0% nice, 1.3% system, 0.0% interrupt, 88.7% idle
Mem: 654M Active, 490M Inact, 5751M Wired, 1136K Cache, 511M Free
ARC: 4847M Total, 2014M MRU, 2364M MFU, 592K Anon, 66M Header, 403M Other
Swap: 1024M Total, 1024M Free
Закрываю RSSOwl, Thunderbird, Deluge:% top
last pid: 8590; load averages: 0.64, 0.61, 0.68 up 0+03:25:40 23:22:47
65 processes: 1 running, 64 sleeping
CPU: 9.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 89.6% idle
Mem: 455M Active, 464M Inact, 5862M Wired, 1092K Cache, 625M Free
ARC: 4961M Total, 2051M MRU, 2440M MFU, 592K Anon, 66M Header, 403M Other
Swap: 1024M Total, 1024M FreeКак видишь, ARC всё-таки изменяет размер не только в большую сторону, но и способен уменьшаться, когда у запускаемых приложений возникает потребность в свободной памяти.
> ARC — это адаптивный кэш. Изменяет свой размер как в сторону увеличения
> (когда идёт кэширование), так и в сторону уменьшения (когда запускаются новые
> приложения и им нужна память).Спасибо, кэп. Вот только делает это сам, по своей внутренней логике, не пересекающейся с логикой ядра. Ядерный же кеш отдает память, как только её запросила система. Немедленно. В пределах работы подсистемы распределения памяти.
> Начинаю копировать большой файл, размер которого больше, чем размер оперативной памяти:
> Запускаю приложения: RSSOwl, Deluge, Firefox, Thunderbird:Дооооолго. Надо сразу запустить приложение, которое сразу захочет приличный объем памяти. Оно либо получит no memory, если свопа нет, либо сразу залезет в своп, и будет там ждать, пока распрекраснейший ARC отдаст память. В случае систем, где >70% памяти свободно - это более-менее приемлемо. В случае нагруженных серверов - в баню.
> Как видишь, ARC всё-таки изменяет размер не только в большую сторону, но
> и способен уменьшаться, когда у запускаемых приложений возникает потребность в свободной
> памяти.Еще раз спасибо, кэп. Только вот то, что память не освобождается кешем по первому требованию - делает его пригодным исключительно для файлопомоек. На остальных применениях - либо ограничивать ручками, либо слишком рискованно.
>> ARC — это адаптивный кэш. Изменяет свой размер как в сторону увеличения
>> (когда идёт кэширование), так и в сторону уменьшения (когда запускаются новые
>> приложения и им нужна память).
> Спасибо, кэп. Вот только делает это сам, по своей внутренней логике, не
> пересекающейся с логикой ядра. Ядерный же кеш отдает память, как только
> её запросила система. Немедленно. В пределах работы подсистемы распределения памяти.
>> Начинаю копировать большой файл, размер которого больше, чем размер оперативной памяти:
>> Запускаю приложения: RSSOwl, Deluge, Firefox, Thunderbird:
> Дооооолго. Надо сразу запустить приложение, которое сразу захочет приличный объем памяти.Да, наверно. Но такого приложения кроме Java (которую можно настроить на захват максимального объёма памяти сразу) у меня пока нет. Надо будет OpenOffice собрать.
> Оно либо получит no memory, если свопа нет, либо сразу залезет
> в своп, и будет там ждать, пока распрекраснейший ARC отдаст память.
> В случае систем, где >70% памяти свободно - это более-менее приемлемо.
> В случае нагруженных серверов - в баню.Как видишь, SWAP оставался незадействованным на всём протяжении эксперимента. Хотя свободной памяти оставалось относительно немного — ARC возвращал системе затребованную вновь запускаемыми приложениями память НЕМЕДЛЕННО.
>> Как видишь, ARC всё-таки изменяет размер не только в большую сторону, но
>> и способен уменьшаться, когда у запускаемых приложений возникает потребность в свободной
>> памяти.
> Еще раз спасибо, кэп. Только вот то, что память не освобождается кешем
> по первому требованию - делает его пригодным исключительно для файлопомоек. На
> остальных применениях - либо ограничивать ручками, либо слишком рискованно.ARC всё же отдаёт память. Уже запущенные приложения и вновь запускаемые не сваливаются в SWAP "до лучших времён". Так что твои выводы беспочвенны.
Кстати, поведение ARC можно легко подстроить через sysctl-переменные для более гибкого управления памятью кэша, чтобы снизить латентность выделения памяти (которую лично я не заметил на своём десктопе), когда часто создаются и завершаются процессы, которым нужна свободная память, а также в ситуации, когда необходимо работать с сотнями-тысячами короткоживущих процессов.
> ARC всё же отдаёт память. Уже запущенные приложения и вновь запускаемые не
> сваливаются в SWAP "до лучших времён". Так что твои выводы беспочвенны.Позволю себе уточнить: это НЕ МОИ выводы.
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuni...
>> ARC всё же отдаёт память. Уже запущенные приложения и вновь запускаемые не
>> сваливаются в SWAP "до лучших времён". Так что твои выводы беспочвенны.
> Позволю себе уточнить: это НЕ МОИ выводы.
> http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuni...И какие конкретно предложения в статье тебе показались трудными для понимания и осмысливания, что ТЫ_СДЕЛАЛ далеко идущие выводы? Давай вместе разберёмся на опыте, поставим эксперимент.
> И какие конкретно предложения в статье тебе показались трудными для понимания и
> осмысливания, что ТЫ_СДЕЛАЛ далеко идущие выводы? Давай вместе разберёмся на опыте,
> поставим эксперимент.чЕтай, чудик. внимательно
Some applications include free-memory checks and refuse to start if there is not enough RAM available - even though the ARC would release its memory based on applications' requests to the OS kernel for memory. Sometimes the ARC can be too slow to release the memory, and better-behaving applications (without preliminary checks) experience longer delays when requesting memory.
Еще раз ДОТ:
Sometimes the ARC can be too slow to release the memory, and better-behaving applications (without preliminary checks) experience longer delays when requesting memory.
>[оверквотинг удален]
> Some applications include free-memory checks and refuse to start if there is
> not enough RAM available - even though the ARC would release
> its memory based on applications' requests to the OS kernel for
> memory. Sometimes the ARC can be too slow to release the
> memory, and better-behaving applications (without preliminary checks) experience longer
> delays when requesting memory.
> Еще раз ДОТ:
> Sometimes the ARC can be too slow to release the memory, and
> better-behaving applications (without preliminary checks) experience longer delays when
> requesting memory.Покажи мне эти "some applications", которые будут себя чувствовать неважно. Хочу увидеть и ощутить всю убогость ARC по неотдаче памяти.
> Покажи мне эти "some applications", которые будут себя чувствовать неважно. Хочу увидеть
> и ощутить всю убогость ARC по неотдаче памяти.http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/3... - нехватка
http://freebsd.1045724.n5.nabble.com/Another-ZFS-ARC-memory-... - свопинг
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-Novem... - проблемы со скоростью высвобождения
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March... - то же самое
https://forums.oracle.com/forums/thread.jspa?threadID=1906687 - падает сервер БД из-за неосвобождения памяти ARCдальше гугли сам
>> Покажи мне эти "some applications", которые будут себя чувствовать неважно. Хочу увидеть
>> и ощутить всю убогость ARC по неотдаче памяти.
> http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/3... - нехваткаОтвет там же: http://permalink.gmane.org/gmane.os.solaris.opensolaris.zfs/...
А проблема заключалась в поиске способа регулировать ARC cache size на лету без перезагрузки компьютера. То есть тюнинг не произведён, компьютер перезагружать нежелательно. Человек боится, что 5 ГБ оставшейся свободной памяти ему не хватит. :))
> http://freebsd.1045724.n5.nabble.com/Another-ZFS-ARC-memory-...
> - свопингГДЕ? Там утечка памяти была и SWAP-шторм, после чего сервер, скорее всего, ушёл на перезагрузку.
> http://mail.opensolaris.org/pipermail/zfs-discuss/2009-Novem... -
> проблемы со скоростью высвобожденияАга — в 2009 году была проблема с быстродействием ZFS.
> http://lists.freebsd.org/pipermail/freebsd-stable/2012-March... - то же
> самоеТам ограничили размер ARC 4 ГБ на 24 ГБ ОЗУ и чего-то жалуются.
> https://forums.oracle.com/forums/thread.jspa?threadID=1906687 - падает сервер БД
> из-за неосвобождения памяти ARCНе могу посмотреть — "The website you are attempting to access is currently experiencing network connectivity errors. The problem is being worked on and will be resolved as soon as possible. We apologize for any inconvenience this may cause and thank you for your patience."
> дальше гугли сам
Ты мне мясо давай, а не ссылки на странные проблемы.
> Ты мне мясо давай, а не ссылки на странные проблемы.Лично для меня уже достаточно вышеперечисленного, чтобы за версту обходить данную поделку по крайней мере до того момента, когда ее приведут в человеческий вид (ака совместят кеш с системным). Потому, что на первом месте - предсказуемость _системы_ в целом, а уже потом - всё остальное. Желающим же жрать кактусы и нарываться на "странные проблемы" - удачи в их нелегком деле.
>> Ты мне мясо давай, а не ссылки на странные проблемы.
> Лично для меня уже достаточно вышеперечисленного, чтобы за версту обходить данную поделку
> по крайней мере до того момента, когда ее приведут в человеческий
> вид (ака совместят кеш с системным). Потому, что на первом месте
> - предсказуемость _системы_ в целом, а уже потом - всё остальное.Оно всё предсказуемо, пока не начнут насильно урезать аппетиты ARC до 4 ГБ.
> Желающим же жрать кактусы и нарываться на "странные проблемы" - удачи в их нелегком деле.Кактусов до сих пор не увидел. Одни лишь положительные моменты в использовании ZFS. SWAP на ZFS практически всегда пустой. (Заполнялся лишь на несколько мегабайт в процессе компиляции Apache OpenOffice). Ещё забавно наблюдать, как при заполненном ARC кэше первый запуск Eclipse уменьшает занятую память с 5,9 ГБ до 5,2 ГБ. (Последующие перезапуски IDE, конечно, не дают такого эффекта, но и скорость загрузки среды повышается в разы по сравнению с первым запуском — за счёт кэширования в ARC.)
>> Ты мне мясо давай, а не ссылки на странные проблемы.
> Лично для меня уже достаточно вышеперечисленного, чтобы за версту обходить данную поделку...ой, бтр значит тоже юзать не будешь? как же так? печалька...
> ой, бтр значит тоже юзать не будешь? как же так? печалька...ой, чукча похоже не читатель... печалька...
>> ой, бтр значит тоже юзать не будешь? как же так? печалька...
> ой, чукча похоже не читатель... печалька...чукча читатель, но с логикой не дружен не чукча.
может тебе накидать ссылок с боольшими багами бтра от лохматого года? ты же выводы делаешь использовать/не_использовать на основании таких ссылочек...
> может тебе накидать ссылок с боольшими багами бтра от лохматого года? ты
> же выводы делаешь использовать/не_использовать на основании таких ссылочек...И все-таки чукча не читатель: BTR "production ready" только в OEL, и только с конца того года. А ZFS объявлена "production ready" еще до всех этих багов. Разницу разжевывать, или сам дойдёшь?
> почему он отключен?Наверное потому что SSD оказываются в роли патронов при этом - бах - покупай новый ssd.
Вот это круто!
Я правильно понимаю, что её можно уже сейчас установить? И, в общем-то, можно безболезненно заменить SSD на новый в случае выхода его из строя.
> безболезненно заменить SSD на новый в случае5 штук SSD = RAID5 + HotSpare - и меняй сколько хошь. (точнее по одному)
>> безболезненно заменить SSD на новый в случае
> 5 штук SSD = RAID5 + HotSpare - и меняй сколько хошь.
> (точнее по одному):)))))))))))))))))))) Он столько не заработает :)))))))))))))))))))))
Дешевле соответствующий объем памяти всунуть
> Дешевле соответствующий объем памяти всунутьСогласен, но мать в которую можно всунуть 5Tb оперативки стоит как BMW 320i
5 терабайт в одну мать? Хм, даже не знал,что такое бывает. А зачем, если не секрет? Это что за поток должен быть, чтобы на кэш надо было >5 Tb SSD?
Просто 5 SSD по терабайту - воткнуть в принципе реально. Воткнуть 5 Тб оперативки... эээ...
Я просто представить не могу применение, когда даже на порядок меньший кэш давал бы выгоду. Либо вы упрётесь в процессор, либо вам вообще никакого кэша не хватит (как с линейной обработкой видео или большими базами данных) или всё можно будет параллельно на кучу машин разложить с общим сетевым стораджем и раскидать каким-нибудь шардингом, чтобы у каждой в кэше свой кусок лежал, если это какой-нибудь CDN.
в базах данных актуально, либо где спроектировано плохо (например facebook сделал flashcache - близкий аналог - для mysql), либо где не так актуальна экономия на железе (скажем если лицензия оракловая на машине стоит $150K, с ограничением по cpu cores)
софтварное решение того что используется в некоторых хардварных раид контроллерах
> софтварное решение того что используется в некоторых хардварных раид контроллерахА в чем между ними разница? Ну, кроме названия, конечно?
хз, возможно в большей гибкости. не пользуюсь ни тем, ни другим :)
>> софтварное решение того что используется в некоторых хардварных раид контроллерах
> А в чем между ними разница? Ну, кроме названия, конечно?в аппаратном варианте - данные по шине между кешем и хранилищем не надо гонять, и вообще это прозрачно для ос всё само происходит.
программный вероятно гибче в плане настроек.
в общем-то эти два решения неплохо вместе должны работать.
Т.е. прям на кристалле кремния гравировали софт хардварный? Или в контроллерах все-таки софт?
разница между hardware и software такая разница между hardware и software
Уж что только не придумают, лишь бы не заниматься исправлением главных недостатков SSD дисков.. Может лучше не придумывать хитрозадые системы с целью получить результат здесь и сейчас, используя некоторые преимущества при куче минусов, а решить ключевые проблемы SSD?
> Уж что только не придумают, лишь бы не заниматься исправлением главных недостатков
> SSD дисков.. Может лучше не придумывать хитрозадые системы с целью получить
> результат здесь и сейчас, используя некоторые преимущества при куче минусов, а
> решить ключевые проблемы SSD?Как ты это себе представляешь и что ты считаешь ключевыми проблемами? А?
он ничего не представляет, он просто п*здит
> он ничего не представляет, он просто п*здитЯ так и подумал, это был сарказм.
В данном контексте решение ключевых проблем - это 64 Гб памяти и кэш винта в ней.
Решает проблемы SSD настолько, что собственно SSD уже и не нужен.
За исключением той проблемы, например, что при экстренном отключении питания весь кэш в ОЗУ теряется, а на SSD что-то остаётся и потом дописывается на диск. Так что не всё так однозначно.
> при экстренном отключении питания весь кэш в ОЗУ теряется,для решения этой проблемы можно добавить на "мамку" пару-тройку ёмких конденсаторов, и обработчик события "экстренное отключение питания" в ядре (или вообще в железе). Это и куда дешевле и проще в обслуживании, и уж точно долговечнее. Но судя по тому, что этого не сделано до сих пор -- эта проблема не особо актуальна, особенно там, где кабель от ИБП до стойки проложен в недоступном для уборщицы месте.
> а на SSD что-то остаётся и потом дописывается на диск.а что там остаётся? Если речь о СУБД, то всё равно транзакцию завершить невозможно. Если "просто данные", то уж лучше оставить на диске неизменённые данные, чем перезаписать "неизвестно как полуизменёнными".
> Так что не всё так однозначно.
> для решения этой проблемы можно добавить на "мамку" пару-тройку ёмких конденсаторов, и
> обработчик события "экстренное отключение питания" в ядре (или вообще в железе).Во первых, оперативка все-таки дороже флешатины. Во вторых - обычная оперативка даже в low power режиме высасывает большую ноутбучную батарею за примерно неделю хранения в ней данных. А сколько проживет конденсатор? 5 минут7 Замечательно. А потом чего? Просирак 64Гб данных? Как мило.
На ноутбуке есть аккумулятор. В связи счем экстренного отключения питания там быть не может при хоть сколько-нибудь вменяемой эксплуатации.
> В связи счем экстренного отключения питания там быть
> не может при хоть сколько-нибудь вменяемой эксплуатации.А в идеальном сферическом мире в вакууме самолеты не разбиваются, корабли не тонут, ДТП невозможны как класс. Проблема только в том что в реальном мире этого не наблюдается.
Ну если вы со включенного ноутбука выдираете аккумулятор - то ССЗБ. Других ситуаций быть не может - если система гасится корректно то всё будет сброшено на диск, разряд батареи тоже отслеживается.
> для решения этой проблемы можно добавить на "мамку" пару-тройку ёмких конденсаторов, и
> обработчик события "экстренное отключение питания" в ядре (или вообще в железе).какую емкость наберете, сколько она будет держать данные по времени, как быстро ваши кондеры будут терять собственную емкость.
допустим нужно продержать питание 60 секунд при вольтаже в 12 вольт и 100 ваттах, если правильно помню:
j/U^2 = T*U*I/U^2 = T*U*(P/U)/U^2 = 60*12*100/12/(12^2) = 41,6(6)Ф
не хилая емкость получается... ионистарами, конечно набрать можно, но...
А тем временем за бугром уже изобрели w:Мемристор, который вот-вот заменит и SSD и RAM
> А тем временем за бугром уже изобрели w:Мемристор, который вот-вот заменит и
> SSD и RAMЭто "вот вот" будет длиться десятки лет из-за первоначальной дороговизны. Флешу уже тоже лет много, однако в mass use в качестве дисков постоянного хранения флеш пошел только что.
"жаль, только жить в это время прекрасное уж не придется ни мне, ни тебе"
это слегка специфично для зачади, не находите? некоторые бъются за каждую лишнюю планку памяти, а вы ими "разбрасываетесь". более того, размеры ssd сейчас чуть побольше, чем оперативка, что вы сможете в блейдик напихать
Ничего, что этим другие люди занимаются? Программист, решающий ключевые проблемы SSD? Кстати, с решением дела вроде неплохо - пробегали новости про флеш сподогревом...
да, а кроме этого разрабатывают еще ReRAM http://science.compulenta.ru/727758/
Там что-то совсем экспериментальное, а подогрев - я так понимаю, через годик живьём увидим. Для кэша, кстати, будет в самый раз- там, помнится, ещё и скорость стирания сильно повышалась, а объёмы большие кэшу ни к чему.
наконец-то
Хорошо бы в ядро протолкнули, а без ядра и так есть flashcache от фейсбука, тестил на стенде - работает
Прочитал руководство по установке и не понял, видимо прозрачно подключить всё же нельзя:http://atlas.evilpiepirate.org/git/linux-bcache.git/tree/Doc...
"Both the cache device and backing device must be formatted before use."
Т.е. к существующей конфигурации 2 HDD -> MD RAID1 -> LUKS -> LVM, в качестве кеша md1 устройства подключить не выйдет без пересоздания всего?
> Т.е. к существующей конфигурации 2 HDD -> MD RAID1 -> LUKS ->
> LVM, в качестве кеша md1 устройства подключить не выйдет без пересоздания
> всего?а между тем flashcache вполне можно подключить, например, к открытому luks устройству и все будет работать без пересоздания
Да, только для flashcache надо отмонтировать FS и потом подключить её с другого устройства.Хотелось бы просто воткнуть SSD как кеш к MD устройству, ничего не переформатирую и не изменяя потом fstab.
Кажется в ZFS это сделано прозрачно, как добавление, так и удаление/поломка SSD.
В zfs так можно потому, что она «не юниксвейная» и на уровни абстракций не побита.
Кому нравится zfs — может просто взять и использовать zfs, да преумножатся род и богатства Белендорфа безмерно.А кто любит юниксвей и святой GPL — не переломится и перемонтировать.
> а между тем flashcache вполне можно подключить, например, к открытому luks устройству и все будет работать без пересозданияне сто́ит кешировать на SSD расшифрованные данные
Круто.
Почти как аналог CacheCade у LSI, а может и лучше.
> Круто.
> Почти как аналог CacheCade у LSI, а может и лучше.Аналог. Что-то ни слова про TRIM. Надо думать, умеет.
...и брюки легко превращаются... превращаются брюки... брюки превращаются... в... Некое подобие ZFS L2ARC, правда, без сквозной целостности данных и метаданных.
> ...и брюки легко превращаются... превращаются брюки... брюки превращаются... в... Некое
> подобие ZFS L2ARC, правда, без сквозной целостности данных и метаданных.L2ARC не умеет writeback-кэширование и этим всё сказано.
>> ...и брюки легко превращаются... превращаются брюки... брюки превращаются... в... Некое
>> подобие ZFS L2ARC, правда, без сквозной целостности данных и метаданных.
> L2ARC не умеет writeback-кэширование и этим всё сказано.Потому что для writeback-кэширования нужно заводить ZIL. И этим всё сказано.
Хорошо хоть не KAMAZ.
+1
зачем это в ядре? кому надо, то и так поставит
> зачем это в ядре? кому надо, то и так поставитК сожалению, API для юзерспейс-кеширования еще не придумано, да и неэффективно/небезопасно это - данные системного кеша через юзерспейс гонять.
Какая-то нездоровая эйфория прослежевается.:) Такое ощущение, что большинство считает, что "кеш блочных устройств на других блочных устройствах" -- это что-то "халявное". А то, что таки нужно держать и поддерживать в памяти актуальную таблицу "кешированных" блоков -- это типа пофиг. И то, что это место (а при размере блока в 512-4096 байт -- это достаточно дофига) в реально быстрой памяти могло бы быть использовано для нормального кеша первого уровня, тоже как бы пофиг.
Даже если предположить, что скорость чтения с SSD порядка 500Мб/с, а скорость чтения с "классического" HDD порядка 40-60Мб/с, то добавление в существующий пул 3-5 обычных "винтов" в зеркале не только практически невилирует разницу, с учётом кеша в оперативке, но и повышает отказоустойчивость.
По кешу на запись. Тут реально есть прямой профит.:) Но неудобство в том, что по объёму кеш реально нужен мизерный (порядка нескольких, возможно сотен, мегабайт). Отсавшийся объёмом купленных SDD остаётся невостребованным. К тому же, в отличии от кеша чтения, который и потерять не жалко, на запись некисло бы иметь пару SDD в зеркале, ибо при отказе одного вы окажитесь в полной ж..., даже при наличии УПСов и ответственных уборщиц:)ЗЫ. Вполне допускаю, что где-то, в каких-то ситуациях кеширование на SSD реально оправдано и приносит дикий профит. Был бы рад почитать об этом. Особенно если ситуация ближе к среднестатистическим объёмам, а не екзобайты данных, на петобайты кеша.:)
>на запись некисло бы иметь пару SDD в зеркалепри этом: разных производителей на разных чипах, дабы одновременно не сколлапсровали.
> Даже если предположить, что скорость чтения с SSD порядка 500Мб/сНе в ту сторону лезете. Hint: скорость доступа, IOPS.
Да с IOPSами тоже не всё так просто. Чтобы они заработали на SSD, нужно чтобы кеш наполнился данными с HDD. Чтобы они продолжали работать, запросы на чтение должны приходить для данных, находящихся уже в кеше. Если очень часто "промахиваться" мимо кеша, то IOPSам это не сильно поможет. Если же подавляющее большинство запросов попадают в кеш на SSD, то возможно, что проще будет создать под эти данные отдельный пул состоящий только из SSD и не тратить впустую оперативку и проц на содержание таблицы кешированных блоков.
В общем эффективность затеи с L2-кешем очень сильно зависит от характера нагрузки.
> Да с IOPSами тоже не всё так просто. Чтобы они заработали на
> SSD, нужно чтобы кеш наполнился данными с HDD. Чтобы они продолжали
> работать, запросы на чтение должны приходить для данных, находящихся уже в
> кеше. Если очень часто "промахиваться" мимо кеша, то IOPSам это не
> сильно поможет. Если же подавляющее большинство запросов попадают в кеш на
> SSD, то возможно, что проще будет создать под эти данные отдельный
> пул состоящий только из SSD и не тратить впустую оперативку и
> проц на содержание таблицы кешированных блоков.
> В общем эффективность затеи с L2-кешем очень сильно зависит от характера нагрузки.Отключите на своем компе кеш процессора, от только зря занимает транзисторы и потребляем миливатты.
> Отключите на своем компе кеш процессора, от только зря занимает транзисторы и
> потребляем миливатты.сравнение лопаты и камаза, казалась бы, а ведь и в то и в другое можно гов-на наложить...