Re: программа для зам еток.
-=Devil_InSide=- wrote: топквоченье - ето как ты или как я ?:) тада не пойму просьбы. В публичных сетевых конференциях не принято топ-квотить. Существует давно сложившийся сетевой этикет, который возник еще до появления WWW и которого желательно придерживаться. А для тех пользователей, кто недавно подключился к сети и ничего про это не слышал - написали RFC. http://tools.ietf.org/html/rfc1855 If you are sending a reply to a message or a posting be sure you summarize the original at the top of the message, or include just enough text of the original to give a context. This will make sure readers understand when they start to read your response. When replying to a message, include enough original material to be understood but no more. It is extremely bad form to simply reply to a message by including all the previous message: edit out all the irrelevant material. И по поводу рюшечек в подписи: If you include a signature keep it short. Rule of thumb is no longer than 4 lines. Remember that many people pay for connectivity by the minute, and the longer your message is, the more they pay. -- maxym -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: программа для заметок.
тогда мы говорим о топ-постенье. и квоченье тут ни при чем ) зыЖ думаю, две лишних строки поминутные соединения потерпят--- ибо разница в загрузке составляет доли секунды. можно пересчитать их побитно и посчитать на среднюю скорость 5-7 кб\сек модема. ну и rfc -- не есть закон, но рекомендуемый стандарт, да. заодно попинай владельцев pgp-signatures. там тоже лишние строки припердоливаются. иной раз даже _кортиночки_. ,--[Maxim Kudelya, Sun, 27 Apr 2008 14:53:17 +0300] |В публичных сетевых конференциях не принято топ-квотить. |И по поводу рюшечек в подписи: | |If you include a signature keep it short. Rule of thumb |is no longer than 4 lines. Remember that many people pay for |connectivity by the minute, and the longer your message is, |the more they pay. | `- -- _ *** * icq: 161874711* * jabber: [EMAIL PROTECTED] * * irc.starlink.ru,#Gene, Devil_InSide * *Registered linux user #450844* *** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Учет компьютеров
Есть ли в Дебиане программа по учету компьютеров? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: программа для зам еток.
Maxim Kudelya пишет: -=Devil_InSide=- wrote: топквоченье - ето как ты или как я ?:) тада не пойму просьбы. В публичных сетевых конференциях не принято топ-квотить. Существует давно сложившийся сетевой этикет, который возник еще до появления WWW и которого желательно придерживаться. Уже объясняли, только ему плевать. Таких товарищей очень хорошо читать procmail'ом. -- With Best Regards, Maxim Tyurin JID:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: программа для заме ток.
On Sun, Apr 27, 2008 at 09:29:02PM +0300, Maxim Tyurin wrote: Уже объясняли, только ему плевать. Таких товарищей очень хорошо читать procmail'ом. +1 -- WBR, Dmitry signature.asc Description: Digital signature
Re: XFS and ReiserFS
On Thu, Apr 24, 2008 at 09:01:06AM +0700, Evgeny Yurkin wrote: В сообщении от 23 апреля 2008 Sydoruk Yaroslav написал(a): On Wed, Apr 23, 2008 at 06:17:43PM +0300, Rodion Brodetsky wrote: Доброго времени суток достопочтенный All! Пишу письмо в эту рассылку не ради флейма, а ради интереса и разъяснения одной проблемы. Меня заинтересовала файловая система XFS. Сам я вот уже 5 с лишним лет использую ReiserFS, но как-то наткнулся на одну статейку (возможно она не очень объективно освещает проблему) и в ней XFS во многих тестах показала себя куда лучше, чем остальные файловые системы. Хочется узнать мнение читателей этой рассылки об этой файловой системе. Кто с ней сталкивался, кто работал, как она проявила себя в повседневной работе и как она по сравнению с ReiserFS ? Уточню что область работы ФС, в моём случае - это обычный домашний компьютер и как следствие файлы и задачи будут самые разнообразные. Эта файловая система предназначена для работы с файлами больших размеров. Как показывает практика не очень надежная файловая система, но для домашнего ПК сгодится. Для продакшина не советую ее использовать. На счет не очень надежна можно поподробней, у меня лет много уже на продакшене живет и проблем не видел, а вот reiser на /var несколько раз слетала, причем 2 раза фатально (комп стоял без ups) и еще в xfs есть xfsdump :) Стояли сервера с xfs (uptime 3-месяца+),при простом ребуте появлялись битые файлы, которые xfs_repair восстановить не мог, причина сего непонятна, так как ребут был корректный, и это на 3-4 серверах из 10. Reirser сразу отвалилась в ro, после небольшого теста на чтение и запись. jfs - хоть весь гугль и работает на ней, но уж очень много битых файлов возникало притом никаких пропадания света. ext3 хоть и медленнее, но зато самая стабильная и надежная, последнее время никаких проблем не было. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFS and ReiserFS
Sydoruk Yaroslav wrote: jfs - хоть весь гугль и работает на ней, но уж очень много битых файлов возникало притом никаких пропадания света. Гуглу, как известно, пофиг вылетание узла, т.к. контент продублирован на других узлах: http://k001.livejournal.com/572563.html -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFS and ReiserFS
On Mon, Apr 28, 2008 at 12:21:07AM +0300, Sydoruk Yaroslav wrote: Стояли сервера с xfs (uptime 3-месяца+),при простом ребуте появлялись битые файлы, которые xfs_repair восстановить не мог, причина сего непонятна, так как ребут был корректный, и это на 3-4 серверах из 10. Reirser сразу отвалилась в ro, после небольшого теста на чтение и запись. jfs - хоть весь гугль и работает на ней, но уж очень много битых файлов возникало притом никаких пропадания света. Если файловые системы наворачиваются на ровном месте (либо при корректной перезагрузке), то я бы скорее задумался про глюки в железе... -- WBR, Dmitry signature.asc Description: Digital signature
Re: XFS and ReiserFS
+1 я гонял по домашним хардам ( xfs, reiserfs, ext3) 700 гигов инфы --- все работало как часы. на работе ни xfs ни ext3 тоже не ломаются от прогонки гигов по 50-100 в неделю (посчитанные большие обьемы, работу пользователей с файлами сюда не включаю). лично для себя после краткого теста на скорость решил оставить reiserfs --- вроде описывают, как самовосстанавливающуюся ,... да и в любом случае проверка ее идет гораздо быстрее, чем ext3. ,--[Dmitry Nezhevenko, Mon, 28 Apr 2008 00:29:30 +0300] | Reirser сразу отвалилась в ro, после небольшого теста на чтение и | запись. jfs - хоть весь гугль и работает на ней, но уж очень много битых | файлов возникало притом никаких пропадания света. | |Если файловые системы наворачиваются на ровном месте (либо при корректной |перезагрузке), то я бы скорее задумался про глюки в железе... `- -- _ *** * icq: 161874711* * jabber: [EMAIL PROTECTED] * * irc.starlink.ru,#Gene, Devil_InSide * *Registered linux user #450844* *** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFS and ReiserFS
On Mon, Apr 28, 2008 at 01:30:04AM +0400, alex kuklin wrote: Sydoruk Yaroslav wrote: jfs - хоть весь гугль и работает на ней, но уж очень много битых файлов возникало притом никаких пропадания света. Гуглу, как известно, пофиг вылетание узла, т.к. контент продублирован на других узлах: http://k001.livejournal.com/572563.html Я не поверю, что у ext3/xfs/reiserfs3/jfs на нормальном железе (неглючном) будут сами по себе пропадать файлы под нагрузкой... -- WBR, Dmitry signature.asc Description: Digital signature
Re: XFS and ReiserFS
On Mon, Apr 28, 2008 at 12:29:30AM +0300, Dmitry Nezhevenko wrote: On Mon, Apr 28, 2008 at 12:21:07AM +0300, Sydoruk Yaroslav wrote: Стояли сервера с xfs (uptime 3-месяца+),при простом ребуте появлялись битые файлы, которые xfs_repair восстановить не мог, причина сего непонятна, так как ребут был корректный, и это на 3-4 серверах из 10. Reirser сразу отвалилась в ro, после небольшого теста на чтение и запись. jfs - хоть весь гугль и работает на ней, но уж очень много битых файлов возникало притом никаких пропадания света. Если файловые системы наворачиваются на ровном месте (либо при корректной перезагрузке), то я бы скорее задумался про глюки в железе... на всех серверах одинаковые железо, поначалу именно на него и грешили. Но на 4-х из 10-ти на ровном месте битые файлы это уже статистика. На эти же сервера было накатано ext3 ни одного битого файла вот уже больше полгода. выбрали приоритетной надежность нежели гнаться за производительностью, хотя каждый строит приоритеты из поставленных задач. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Управление приоритето м трафика.
Помогите с управлением приоритетами трафика. Задача такая: Есть десктоп, интернет через pptp , устройство ppp0. Входящий трафик ограничен 256Кбит, исходящий 100Кбайт примерно. Канал все время забит на 100% всякими торентами и прочими загрузками. Хочется каким то образом наладить работу сетевого интерфейса что бы, некоторые типы соединений (ssh,rdp) имели безусловный приоритет над всем остальным, вплоть до полной остановки загрузок ежели это требуется. Ну и опционально выделить веб трафик и засунуть его по приоритету между ssh и загрузками, возможно ограничив по ширине полосы. Почитал lartc, поставил iproute2 и пробую что то вроде такого. tc qdisc add dev ppp0 root handle 1: htb default 30 tc class add dev ppp0 parent 1: classid 1:1 htb rate 800kbit burst 15k tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 800kbit burst 15k tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 100kbit ceil 800kbit burst 15k tc class add dev ppp0 parent 1:1 classid 1:30 htb rate 10kbit ceil 800kbit burst 15k tc qdisc add dev ppp0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev ppp0 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev ppp0 parent 1:30 handle 30: sfq perturb 10 U32=tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 $U32 match ip dport 22 0x flowid 1:10 $U32 match ip dport 3389 0x flowid 1:10 $U32 match ip dport 80 0x flowid 1:20 Но похоже я что то не так делаю. Во первых лаги на соединениях rdp/ssh все равно не приемлимы. Во вторых незаметно что б скорость торентов менялась хоть как то. Эксперементировал с цифрами, занижал ширину канала в разы, в итоге tc -s qdisc ls dev ppp0 начинает показывать dropped пакеты в низкоприоритетной очереди 30, но удобство работы не меняется. По всей видимости я что то делаю не так. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Управление приори тетом трафика.
apm wrote: Помогите с управлением приоритетами трафика. Задача такая: Есть десктоп, интернет через pptp , устройство ppp0. Входящий трафик ограничен 256Кбит, исходящий 100Кбайт примерно. Канал все время забит на 100% всякими торентами и прочими загрузками. Хочется каким то образом наладить работу сетевого интерфейса что бы, некоторые типы соединений (ssh,rdp) имели безусловный приоритет над всем остальным, вплоть до полной остановки загрузок ежели это требуется. Ну и опционально выделить веб трафик и засунуть его по приоритету между ssh и загрузками, возможно ограничив по ширине полосы. По всей видимости я что то делаю не так. Конечно не так. QoS, по определению, можно делать только для исходящего трафика. Входящий трафик -- совокупность случайных событий, но и его, в принципе, можно буферизовать, потом сортировать и передавать дальше по стеку. В Linux есть псевдоустройство IFB, позволяющее применять стандартные дисциплины очереди ко входящему трафику. Можно попробовать с ним, но эффект на забитом канале будет невелик. Гораздо эффективнее просто ограничить входящий трафик в torrent-клиенте, так чтобы для ssh хватало. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFS and ReiserFS
On Mon, Apr 28, 2008 at 01:30:04AM +0400, alex kuklin wrote: Sydoruk Yaroslav wrote: jfs - хоть весь гугль и работает на ней, но уж очень много битых файлов возникало притом никаких пропадания света. Гуглу, как известно, пофиг вылетание узла, т.к. контент продублирован на других узлах: http://k001.livejournal.com/572563.html Совершенно верно, они сделали на основе jfs или ext3 свою gfs, цель которой хранить репликацию файла на других серверах. http://youtube.com/watch?v=3G9H7FhnQogfeature=related http://labs.google.com/papers/gfs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Управление приори тетом трафика.
Stanislav Kruchinin пишет: Конечно не так. QoS, по определению, можно делать только для исходящего трафика. Входящий трафик -- совокупность случайных событий, но и его, в принципе, можно буферизовать, потом сортировать и передавать дальше по стеку. В Linux есть псевдоустройство IFB, позволяющее применять стандартные дисциплины очереди ко входящему трафику. Можно попробовать с ним, но эффект на забитом канале будет невелик. Гораздо эффективнее просто ограничить входящий трафик в torrent-клиенте, так чтобы для ssh хватало. Понимаете, идея ограничить ширину в торрент клиенте работает, но очень не удобно. Во первых неясно до какой величины ограничивать, во вторых хочется таки что б при отсутствии ssh/rdp качало в полную силу. А так как в процессе работы за компом открыто то одно то десяток ssh соединений+пяток rdp постоянная возня с ограничениями утомляет. Да к тому же бывает запущен какой нить wget , aptitude upgrade и прочее. Руками регулировать черезчур мутно. Я понимаю что на входящий трафик напрямую не повлияешь. Но хотел повлиять как бы косвенно. Согласно моим заблуждениям, если торрент (и прочим качающим клиентам) занизить скорость исходящего канала, то это как то должно привести к урезанию и входящего. Шлют же они какие нить метки пакет получен, запрашивает новые блоки? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: программа для заметок.
Maxim Tyurin - debian-russian@lists.debian.org @ Sun, 27 Apr 2008 21:29:02
+0300:
-=Devil_InSide=- wrote:
топквоченье - ето как ты или как я ?:)
тада не пойму просьбы.
В публичных сетевых конференциях не принято топ-квотить. Существует
давно сложившийся
сетевой этикет, который возник еще до появления WWW и которого
желательно придерживаться.
MT Уже объясняли, только ему плевать.
MT Таких товарищей очень хорошо читать procmail'ом.
Да, я тоже уже до этого созрел.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Мне еще спать под рутом (С)энта
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Управление приоритетом трафика.
apm - debian-russian@lists.debian.org @ Mon, 28 Apr 2008 04:51:25 +0600:
a Я понимаю что на входящий трафик напрямую не повлияешь. Но хотел
a повлиять как бы косвенно. Согласно моим заблуждениям, если торрент
a (и прочим качающим клиентам) занизить скорость исходящего канала, то
a это как то должно привести к урезанию и входящего. Шлют же они какие
a нить метки пакет получен, запрашивает новые блоки?
Нет, если занизить скорость исходящего, это не повлияет. Они и так
исходящий почти не используют - пакеты подтверждения намного меньше
пакетов с содержимым. Размер TCP-шного окна уменьшать эффективно
(ограничение скорости на клиенте именно так и реализовано, насколько я
понимаю), но принудительное уменьшение окна без ведома выставившего его
процесса - дело такое, от этого трафик может возрасти... Либо
придерживать пакеты подтверждения - отправлять их не сразу, а чуть
погодя. Но логика принятия решения тут будет весьма сложной, и я
сомневаюсь, что существуют готовые средства...
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
/dev/null-транспортировка
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
