| 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.
| | |
| |
| |
| 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 +/– | |
> очередной троль - который не потрудился посмотреть исходники.
Спасибо, что прочитали мой ник. А Вы тире не к месту употребили ;)
| | |
| |
| |
| |
| |
| 7.48, Аноним (-), 17:02, 27/05/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> С чего ты взял что я за хренами наблюдаю? :D
Судит всех по себе, видимо.
| | |
|
|
|
|
| 3.60, Аноним (-), 19:21, 27/05/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> очередной троль
Ты настолько лузер, что даже слово "тролль" не можешь правильно написать. Позор!
| | |
|
|
| 1.3, cmp (??), 11:46, 27/05/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Дык линукс же и так кеширует весь обмен с фс в ОЗУ, то есть, хошь ускориться добей оперативы; сервера нагруженные, так ведь там и железо соответстующее, в крайнем случае есть своп, который как раз и можно держать на ссд или сас, если данные в оперативу совсем не лезут, в чем профит?
| | |
| |
| 2.7, Andrey Mitrofanov (?), 11:59, 27/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Дык линукс же и так кеширует весь обмен с фс в ОЗУ,
> то есть, хошь ускориться добей оперативы;
Ну, как бы тех, кто пишет и использует БД интересует момент окончания _записи на ...[ммм, как это есть по-русски]... non-volatile носитель.
> в крайнем случае есть своп, который как раз и можно держать на ссд
:*)))
| | |
| |
| 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.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 +/– | |
> Процессу можно сказать, что данные есть, "- а где и как - тя нипёт!".
Можно. Только когда у тебя при крахе потом навороченный двигун БД не сможет отреплеить свой журнал и транзакционность факапнется - будешь писать жалобы в спортлото и копить деньги на оптовую закупку вазелина.
| | |
|
|
|
| |
| 2.25, Аноним (-), 12:52, 27/05/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> еще бы совместно с EPRD заюзать, будет просто супер!
А разве EPRD не блочное устройство?
Или BTIER блочные устройства не поддерживает?
| | |
| 2.65, saNdro (?), 21:43, 27/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
Так никто и не мешает их юзать параллельно. Можешь не сомневаться. ERPD был убран из TIER автором уже вроцессе развития, что бы не дублировать код проекта. Автор, кстати, у них один и тот же.
| | |
|
| |
| 2.24, Аноним (-), 12:43, 27/05/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Distributed Replicated Block Device
для тех кто не понял, это было на "сетевые разделы DRDB"
| | |
|
| |
| 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 измеряют в циклах записи а то и... текст свёрнут, показать | | |
|
|
|
|
|
|
| 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.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.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'е там сегодня
> речи быть не может.
Потому что он там в пень не уперся. Она чутка для других задач, нежели самодельное гогно.
| | |
|
|
|
| 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.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 [^] [^^] [^^^] [ответить]
| +/– |
Нужна.
Во-первых, реализации аля кэш уже есть. Пользуйтесь.
Во-вторых, вот есть у меня ноут. Двд сменил на ссд. Вот сабж более чем к месту тут.
В-третьих, в случае кэша в/в всё равно дублируется. Что может быть критично. Графики выше.
| | |
|
| |
| 2.85, Кирилл (??), 12:45, 30/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
Вот есть у вас очень быстрый ссд, но он мелкий и относительно дорогой, и есть очень большой и дешёвый, но медленный жёсткий диск. Вы можете сами раскладывать то, что по-вашему, требует быстрого чтения и редко изменяется на быстрый ссд, а жёсткий диск использовать для данных, которые не так критичны к скорости загрузки. Но как определить что куда класть, да и следить за этим нужно. В общем, слишком много мороки. А эта технология позволяет залепить из ссд и жёсткого диска один раздел, а потом сама ведёт статистку использования и решает какие файлы (или блоки) на какой физический носитель пихать. За счёт этого конечный пользователь получает и высокую скорость загрузки и преимущества большого и дешёвого носителя.
| | |
|
|
