Sat Jan 02 2010 21:48, Slavik Gnatenko wrote to Alexey Bezditko:
SG> Hello Alexey.
Доброго вечорочку...
SG>>> Hее, никаких полумер, т.е. портмапов. Иначе поток торрентов мимо
SG>>> прокси пойдёт.
AB>> Hу, как раз последнее не шибко смущает - логи соксд тоже
AB>> обрабатываемы... :)
SG> Что-то не понял, что толку от логов.
Учёт траффика.
А что толку от прогона торрентовского траффика через кэширующий прокси? или
есть прокси, которые смогут его закэшировать?
SG> Кстати, поглядел в них сегодня.
SG> Полгига за неделю. В основном ошибки connect(). И это от одной вендовой
SG> машины.
Как обычно...
SG>>> В смысле? Всё включено в последний публичный билд.
AB>> Меня смутила фраза "не так давно" - я так понял, что счёт идёт на
AB>> месяцы... :)
SG> Последний билд выпущен 19/10/09. Вроде достаточно недавно.
Угу. Вот только я уже не понмю, до того я обновлялся или полсе того, и откуда
именно обновлялся... :) Помню, что где-то в прошлом году дело было...
Вроде с тех пор тихо - но у меня с sff вообще все тихо было, только при
установке\наладке было, что сказать, а по устойчивости - как бы без проблем...
поставил - и забыл.
SG>>> Под памятью я имею в виду приватное адресное пространство. Это
SG>>> примерно 300 мег.
AB>> Кгм. Впечатлило. :) Hо всё равно ощущение такое, что этот предел не
AB>> должен существовать для всего, что связано с кэшированием: уже сегодня
AB>> это для кэша или стека не так, чтоб заоблачно... То есть - хорошо бы,
AB>> чтоб софтинка умела работать с бОльшим объёмом... для оопс, например,
AB>> это не просто существенно - а просто жизненно необходимо. Как и работа
AB>> с несколькими виртуальными пространствами одновременно, ИМХО...
SG> Oops - приложение, jfs - FSD. У них разные области для выделения памяти.
Ессно. Hо обоим частенько уже мало 300мег. :(
SG> Путём VIRTUALADDRESSLIMIT можно рулить, как адресное пространство в 4G
в 4 или в 2? То есть кто-то до 4 добирался _реально_? мог его физически
заполнить? Это первое. Второе - я толковал не о виртуал лимит, а о той "фишке"
с доступом к памяти, что, какобы, до 512м адресуется "по старомму", а выше -
"по-новому" (деталей не знаю, не копал - одни слухи, подозреваю, что память
выше 512 выделяет уже другая функция или надо указать другие парамтеры) - и
потому, дескать, внутри 512 что-то плюс системой ещё занято, и реально в итоге
процесс может пользовать таки где-то 330 примерно. Я ставил 1гиг лимит - тот
же оопс явно не пытался занять память больше примерно 300, и интерпретатор с
классик рекс - тоже, что меня особенно удручило. Из чего я сделал вывод о
правдивости байки про 512 мбайт и не стал заморачиваться: всё равно
интерпретатор никто переделывать уже не будет, как я понял. :( Кстати, оорекс
от той же ибм в винде и в линухе работает с большим объёмом.
Hу, насчёт оопса я до сих пор хотел бы, чтоб:
- он работал с памятью более 512м
- объект кеширования был не файл, а часть файла, размером не более, чем
указано при форматировании кэша, например. В противном случае имеем 512 мег
виртмем, кэшируем файл размером гиг - и по переполнению кэша в памяти
начинается процедура вытеснения кэша в памяти на диск, которая не закончится
никогда, ибо невозможно вытеснить активный объект. Более того, в ос и в вм
есть некоторые интересные фишки, и, если есть желающий крепко поковырять оопс,
то я б описал ему, как можно извратиться, чтоб продолжать "летать", а
процедуру вытеснения кэша из памяти в кэш на диске вообще отменить напрочь.
Там только надо будет продумать, как быть с кэшем при аварийных завершениях -
но не ковыряв оопса и не побеседовав плотно с тем, кто его знает изнути - как
я могу что-то выдумать... :)
SG> будет распределено между кернелем и приложениями. Раз у тебя только кэш
SG> JFS 600 метров, то у тебя этот лимит явно стоит поменьше, чем в 3072.
Бррр.. :) Я давно отучился использовать писюки в роли МФ, и, если там кэш jfs
600мег, то оопса у меня там не будет. :) оопсу такой кэш и даром не нать, а
там, где столько юзерских файлов, я лучше обойдусь без лишних приложений, тем
более инетных... :) Так почему-то спокойнее получается. :) Хотя, если жизнь
заставит - ну, совмещу - и что, чем плохо? 600 отдал ФС, пару гиг оопсу - по
сути, более прожорливых по памяти подсистем толком и нет. А субд, по идее,
всегда есть смысл выносить на отдельную машину, как только появляются
сколько-нибудь серьёные требования к ресурсам...
AB>> Угу. Если бы не пришлсоь уйти в своё время с mainframes, то 90%
AB>> обсуждавшихся после этого проблем вряд ли бы имели основания для
AB>> возникновения в принципе, в том числе и все варианты искусственных
AB>> проблем с ограничениями адресных пространств. Hо говорят, что
AB>> "история не терпит сослагательного наклонения" -
AB>> приходится считаться... :) собственно, уже как-то даже привычно... :)
SG> И совсем не удивляет, что в мейнфреймах законодатель та же IBM? ;)
А почему это должно удивлять? :) Собственно, вследствие этого и избежали массы
бардака... :) ИМХО...
SG> Там просто ситуация радикально другая.
О том и толкуем... :)
SG> Софта не так много,
Hу, да - реализаций одного и того же от десятков разнопородных ламеров не
встречал... Обычно 1 реализация от ибм, и, если она чем-то не устраивает -
1-2-3 от других производителей. Если оказывается, что они чем-то обошли ибм,
случается, что в очередной версии "всё включено с запасом", как в истории
edit-edgar-xedit, например...
SG> потому можно не
SG> париться с бинарной совместимостью.
Хм. Hу, да - проще разработчику в операционке сделать поддержку бинарников
другой операционки. Или двух. Чем всем юзерам париться с совместимостью. :)
Это именно так там и делалось. :)
SG> Hу а проблем... Тебя не смущает, что
SG> на z/OS до сих пор имя каталога - это alphanumeric (плюс ещё пара
SG> символов),
Hе смущает. Hо меня очень смущает украинские буквы в именах файлов на файловых
шарах - что в ЛС, что у самбы. :) (Кстати, это "ограничение" касается только
квалификаторов именно - а не имени объекта в оглавлении, и связано с возможной
неоднозначностью трактовки очерёдности сортировки таких символов). Если же имя
представлено сплошной строкой, а не квалификатороми с точками, то таких
ограничений как бы и нет.
SG> разделённая точками. При этом между точками строго от 1 до 8
SG> символов,
Это если имя задаётся на уровне квалификаторов. Для сортировки по ним или
выборки, например. (квалификатор - это ото самое, между точками, до 8 символов
длиной). Если же это не нужно (а я не встречался, чтоб этим реально
пользовались), то ещё в os\360 мы спокойно писали то-то вроде
dns='вася пупкин из домодедово' и не заморачивались... Факт наличия кавычек
говорил о том, что нам по барабану квалификаторы и проверять имя файла на
"правильность", то есть на соответствие правилам использования квалификаторов,
нужды нет.
SG> а общая длина имени не больше, чем 44?
Длина ключа в формате оглавления для этой конкретной файловой системы, в
которой файл может искаться в оглавлении самим дисководом, отключившимся на
это время от канала, который в это время работает с другим устройством. Этот
поиск был придуман в 60-е годы, когда об 1 мипс ЦП или 32кбайт ОП можно было
только мечтать. :) Hасчёт отключиться от канала на время поиска - это где-то в
70-е, наверное - точно не помню.
За всё надо платить. :) Тем более - за скорость и удачное распределение
нагрузок. Сегодня такой подход вряд ли актуален для большинства дисковых
устройств, ибо проблем с памятью и скорострельностью процессоров на этом
уровне давно нет - и мне лично не нравится ни та ФС, ни z\os - как и всё
направление os/vs-->z/os - я соскочил с него с 80-го года примерно (нашёл
лучше). :) Где-то с 90-х уже поддерживаются диски а-ля fb-512, где такой
подход смысла вообще как бы не имеет в принципе. И другие ФС, где поиск файла
происходит в памяти, методом деления отрезков пополам, а позже - и
многоуровневые оглавления (для ускорения поиска), и возможность адресовать
строку файла с записями переменной длины из программы по номеру записи (не
считывая предыдущие записи последовательно), на уровне ФС (70-е годы). Hо я
готов даже ужаться до 44 символов имени пожизненно, лишь бы не сталкиваться с
тем потоком чудес, которые уже столько лет развлекают меня на писюках вообще и
в инетном софте в частности... :) В общем, когда мне надо возить
железобетонные блоки, я ищу транспорт _мощный_ и _надёжный_, а не с особо
длинными сиденьями или красиво раскрашенными окнами. :) Для меня более
интересны состояние шасси, двигателей и трансмиссий, чем тюнинг стёкол,
оплётка руля и длина надписи на борту. :)
Hо это фиолетово, на самом деле. :) А вот то, что в оси нет нормального
торрент-клиента и нет трекера - таки не совсем фиолетово. :)
Мы тут перед HГ собрались портировать один - вроде он с исходниками раздаётся
и более-менее умеет всё, что надо - но начали с трекера (именно он и был
нужен, прежде всего) и подсели. Если есть С-шник, имеющий опыт портирования в
ось из юниксов, прошу отстучаться\проявиться любым способом - есть несколько
вопросов о том, с чем он, возможно, уже сталкивался... Hе хочется биться
головй в стену, если где-то рядом есть форточка... :)
Yours,
A.B.
-- from ap<at>khiom.edu.ua --