Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
[RC5] Inside the cow 02.04.03 20:28 Число просмотров: 1341
Автор: jammer <alex naumov> Статус: Elderman
|
> Не пробовал, вместо того, чтобы все тачки на одну сводить
> сделать типа древовидной структуры (понятно, что не все
> компы всегда включены, но большие буфера и активный
> Additional buffer-level checking должны помочь) ?
создать проблему, а потом решать ее тем, что должно бы помочь. неа, нафик. я думал об этом. на самом деле когда ничего не виснет, все нормально работает. а отслеживать возню на 5 машинах вместо одной - это слишком. скоро бльшая сетевая перекурочка, заодно и перпрокси будет.
> кстати, сколько у тебя тачек (если не секрет) и какого
60 или 70, точно не помню.
уровня около 1000 блоков в сутки. +- точно не помню.
> уровня? и сеть насколько быстрая и насколько загружена...
100, не сильно. проблема в кормящей корове со слабым целероном.
> к тому же не пытался оптимизировать настройки твоей
> центральной (расшареной) машины? ну и сети до кучи
все что можно, сделал. :) даже от злобы дня погнал с 266 на 416 :)
> ;-) может вообще - клиента взломать и быстренько все блоки
> вернуть обратно как никудышные - процентов до 90 кейспейса
> все будут думать, что так и надо, а потом кинутся
> проверять, да поздно (прецеденты уже есть - RC5-64)
это уже неинтересно, даже если бы было реально. впрочем, у тебя есть право попытаться.
|
|
<dnet>
|
[RC5] Inside the cow 01.04.03 22:25
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 01.04.03 22:30 Количество правок: 1
|
все началось с того, что 2 раза висла машина с расшаренными сетевыми буферами. все бы хорошо - но совпало это с апдейтами ремотных буферов от других машин. (наверное, черезчур много машин для такой организации нужного обществу процесса, как файл-шаринг, но сейчас пока ситуация такова, воспримем ее как условие задачи).
корова как вы знаете не только сам ремотный файл блокирует при апдейте ремотных буферов, но и внутри файла хитрый признак прописывает остальным сестренкам - мол, обновляюсь, копыта прочь. естественно, после некорректной перезагрузки данный признак в файлике запросто может залипать. в результате может получиться ситуация что основной входной или выходной буфер блокируется "навсегда". таймаутов у зверя не предусмотрено - это вам не binkd, на полный автопилот не рассчитано.
пример такого файлика можете взять по нижеприведенной ссылке.
об этом эффекте я знал давно. переименовал его раз, два... когда суммарно "залипло" больше 100 старательно и аккуратно просчитанных статюнитов - меня это децл поддостало. в результате делюсь информацией:
--------------------------- buff-*.r72 ---------------------------
сигнатура
00000000: 83 B6 34 1A
предположительно резёрвед
00000004: 00 00 00
="48" - видимо признак буфера рц5-72. младший бит - файл блокирован (!)
00000007: 48
а здесь явно содержится количество блоков данного буфера
самое интересное - порядок записи от старшего к младшему (why so?)
00000008: 00 00 00 00
это пример:
00000000: 83 B6 34 1A 00 00 00 48 ¦ 00 00 03 C2 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 ¦ 00 00 00 00 00 00 00 00
--------------------------- buff-*.r72 ---------------------------
соответственно, в случае систематического сообщения о невозможности работы с заблокированным буфером (перезагрузка не помогает) - восьмой байтик (седьмой если считать от нуля) исправляете с "I" обратно на "H" - по идее почти всегда там и должно быть "H". естественно не забывайте чтобы все то, что дальше, не съехало туда-сюда, а осталось по тем же смещениям. прогу консольную писать или нафик никому не надо?
туша (тело) буфера начинается с 33-го байтика. где у него прописывается признак входящих/исходящих блоков (например как оно различает по -import) - ума не приложу. может прямо в самих блоках, скорее всего, значит можно и входящие и исходящие хранить в одном файле?! интересно подергать как-нить на досуге :)))
можете взять это (10К) и попробовать слить на днет.
|
|
[RC5] Inside the cow 02.04.03 23:59
Автор: Mosich <Mosichev Valentine> Статус: Member
|
> соответственно, в случае систематического сообщения о
> невозможности работы с заблокированным буфером
> (перезагрузка не помогает) - восьмой байтик (седьмой если
> считать от нуля) исправляете с "I" обратно на "H" - по идее
> почти всегда там и должно быть "H". естественно не
> забывайте чтобы все то, что дальше, не съехало туда-сюда, а
> осталось по тем же смещениям. прогу консольную писать или
> нафик никому не надо?
dnetc -forceunlock <fn> unlock buffer file <fn>
читайте доки, они рулез
|
| |
[RC5] Inside the cow 03.04.03 22:03
Автор: jammer <alex naumov> Статус: Elderman
|
> dnetc -forceunlock <fn> unlock buffer file <fn>
> читайте доки, они рулез
круто :)
а чем исправлять если, к примеру, количество блоков в буфере нае6нется? :)
|
|
[RC5] Inside the cow 01.04.03 22:58
Автор: mss <Сергей> Статус: Member
|
Не пробовал, вместо того, чтобы все тачки на одну сводить сделать типа древовидной структуры (понятно, что не все компы всегда включены, но большие буфера и активный Additional buffer-level checking должны помочь) ?
кстати, сколько у тебя тачек (если не секрет) и какого уровня? и сеть насколько быстрая и насколько загружена...
к тому же не пытался оптимизировать настройки твоей центральной (расшареной) машины? ну и сети до кучи
исследование интересное - припоминаются годы молодые (конец 80-х - начало 90-х)
;-) может вообще - клиента взломать и быстренько все блоки вернуть обратно как никудышные - процентов до 90 кейспейса все будут думать, что так и надо, а потом кинутся проверять, да поздно (прецеденты уже есть - RC5-64)
|
| |
[RC5] Inside the cow 02.04.03 20:28
Автор: jammer <alex naumov> Статус: Elderman
|
> Не пробовал, вместо того, чтобы все тачки на одну сводить
> сделать типа древовидной структуры (понятно, что не все
> компы всегда включены, но большие буфера и активный
> Additional buffer-level checking должны помочь) ?
создать проблему, а потом решать ее тем, что должно бы помочь. неа, нафик. я думал об этом. на самом деле когда ничего не виснет, все нормально работает. а отслеживать возню на 5 машинах вместо одной - это слишком. скоро бльшая сетевая перекурочка, заодно и перпрокси будет.
> кстати, сколько у тебя тачек (если не секрет) и какого
60 или 70, точно не помню.
уровня около 1000 блоков в сутки. +- точно не помню.
> уровня? и сеть насколько быстрая и насколько загружена...
100, не сильно. проблема в кормящей корове со слабым целероном.
> к тому же не пытался оптимизировать настройки твоей
> центральной (расшареной) машины? ну и сети до кучи
все что можно, сделал. :) даже от злобы дня погнал с 266 на 416 :)
> ;-) может вообще - клиента взломать и быстренько все блоки
> вернуть обратно как никудышные - процентов до 90 кейспейса
> все будут думать, что так и надо, а потом кинутся
> проверять, да поздно (прецеденты уже есть - RC5-64)
это уже неинтересно, даже если бы было реально. впрочем, у тебя есть право попытаться.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
