Отправляет email-рассылки с помощью сервиса Sendsay

запорчены файлы на разделе

цепь событий:
1 - все замечательно работает
2 - выключаю сервер корректно, меняю память на новую и большую
3 - тестирую память сутки - все замечательно
4 - загружаюсь - идет автоматическая (по прошествию 185 дней без
проверки) проверка файловых систем (ext3) - ошибок не выдает
5 - грузится дальше, вижу странное сообщение из полэкрана нечитаемой
псевдографики, затем "не могу запустить бинарный файл" - почему так
пойму позже
6 - в результате обнаруживаю, что на одном из разделов почти все файлы
содержат мусор (части бинарных программ и т.д.), причем размеры файлов
правильные

запорченный раздел находится на рэйд массиве 5 уровня, массив по всем
признакам живой
система находится на отдельном диске и вроде не пострадала

что это? проверка файловых систем осчастливила?

что делать? можно ли восстановить? на раздел сам ничего не писал
может с запасного супер блока?

спасибо за конструктивные предложения!

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37341; Возраст листа: 2695; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1327825

Ответить   Fri, 10 Dec 2010 18:42:25 +0300 (#1327825)

 

Ответы:

В райдах не разбираюсь - может связано с ним.

Однако если раньше проверка проводилась хотя бы
раз и не вызывала проблем, а память была потревожена - вероятно она.

Память же надо погонять на хороших, **греющих** тестах, если они сейчас
существуют, конечно (раньше был testmem).

Что делать ? Не знаю, но главное не паниковать и не наделать ухудшения ситуации.

ИМХО - вначале вернуть старую конфигурацию памяти. Сохранить дисковый массив
в файл (cat /dev/xxX | bzip2 -9 > image.bz2). А дальше думать, что могла попортить
битая память в Ext3.

Я везде пользую ReiserFS и она не только не подводила при нередком случайном
выключении питания,
но и позволила однажды выправить ситуацию, вызванную глюками перегрева южного
моста.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37342; Возраст листа: 2695; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1327928

Ответить   Fri, 10 Dec 2010 20:08:57 +0300 (#1327928)

 

есть testmem86, входит в состав многих LiveCD, например http://slax.org (200Мб.
2 варианта - USB & CD-ROM)

On 20:08 Fri 10 Dec , Alexander wrote:

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37346; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1328475

Ответить   Fri, 10 Dec 2010 20:28:29 +0300 (#1328475)

 

10 декабря 2010г. 20:28 пользователь drBatty <drbat***@d*****.ru> написал:

Он к сожалению у нынешней памяти тестирует в основном регистр строки.
Соответственно и находит лишь самые явные ошибки.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37347; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1328829

Ответить   Sat, 11 Dec 2010 11:32:45 +0300 (#1328829)

 

On 11:32 Sat 11 Dec , Serguey Khvatov wrote:

пруфлинк можно?

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37349; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1329299

Ответить   Sat, 11 Dec 2010 11:43:02 +0300 (#1329299)

 

11 декабря 2010г. 11:43 пользователь drBatty <drbat***@d*****.ru> написал:

Можно: личный опыт.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37350; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1329328

Ответить   Sat, 11 Dec 2010 17:55:53 +0300 (#1329328)

 

On Sat, 11 Dec 2010 11:43:02 +0300
drBatty <drbat***@d*****.ru> wrote:

Дело в том, что нужен пруфлинк на то, что memtest86 **греет** память, а не наоборот.

Я не нашёл ни в http://www.memtest86.com/ ни в http://www.memtest.org/ никаких
упоминаний
про нагрев. Да и разработчик testmem наверняка знал о существовании memtest.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37351; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1329472

Ответить   Sat, 11 Dec 2010 20:48:24 +0300 (#1329472)

 

11 декабря 2010г. 20:48 пользователь Alexander <aral***@m*****.ru> написал:

наоборот.

Насчёт термина **греющих** - это к тому, кто его употребил. Я так
понял, что этот термин был употреблён исключительно для красного
словца и к реальному нагреву отношения не имеет.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37352; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1329496

Ответить   Sat, 11 Dec 2010 20:35:54 +0300 (#1329496)

 

On Sat, 11 Dec 2010 20:35:54 +0300
Serguey Khvatov <s.xbat***@g*****.com> wrote:

Это вряд ли. ;)

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37353; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1329614

Ответить   Sat, 11 Dec 2010 22:23:52 +0300 (#1329614)

 

http://testmem.narod.ru/mtest.htm

А старого сайта, где это ещё подробнее описывалось уже нет.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37354; Возраст листа: 2696; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1329648

Ответить   Sat, 11 Dec 2010 22:54:33 +0300 (#1329648)

 

Alexander пишет:

Райд аппаратный на контроллере DAC960, в эксплуатации уже 7 лет.
Проблемы по мелочи были замечены когда периодически слетал загрузчик
lilo (RedHat 9 тогда стоял), но данные не пропадали. Хотя совсем его и
не отметаю.
Надо будет попробовать прошивку обновить.

Да, есть причино-следственная связь получается.
Но с другой стороны почему только один раздел? Область памяти ему
досталась битая?

Гонял memtest -ом сутки, ошибок 0, правда режим ECC почему-то так и не
удалось включить в тесте.

Не хотелось бы, чтобы это была память - денег немалых стоит, только
купили :)

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37377; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331178

Ответить   Mon, 13 Dec 2010 09:57:45 +0300 (#1331178)

 

On Mon, 13 Dec 2010 09:57:45 +0300
avm7work <avm7wo***@m*****.ru> wrote:

Возможно, он имел ошибки, а другие не имели. Как только исправил - произошла
операция
записи на диск и записалась "FAT" из битой памяти. Теперь записи в "FAT" указывают
на случайные сектора вместо нужных.

memtest как я понял не греет память. Грел только testmem, но автор его под ДОС
перестал
развивать и пошёл в Вин. Теперь memtest поддерживает чипсеты, но тестирует бесполезно,
а testmem хорошо тестирует память, но знает только старые чипсеты, а вместе -
никак.

Ключевой момент в нагреве. Можно сколько угодно долго тестить, но пока тест не
будет греть
как при реальной работе - без пользы - основные ошибки начинают проявлять себя
только при нагреве.

Пофиг - есть же гарантия.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37385; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331886

Ответить   Mon, 13 Dec 2010 17:38:08 +0300 (#1331886)

 

Alexander пишет:

сделал образ раздела и примонтировал со первым по счету резервным
суперблоком - ура, данные восстановились
стал копировать сами файлы на другой диск - через несколько процентов
загнулся сервер - завис напрочь
при загрузке начал выдавать ошибки на "consystence" - это понятно еще,
дальше хлеще - Processor #1 Error и еще какая-то Error
сброс настроек в setup помог, вошел в настройки контроллера и сейчас
едет consystence check....

что будет дальше - пока не понятно, но raid придется похоже больше не
использовать - прочитал о нем много нелестного, даже обновлять прошивку
судя по отзывам небезопасно - может еще хуже стать

ДОС

бесполезно,

-

не

система охлаждения довольно мощная - не думаю, что она там очень греется
даже при работе

эта память месяц с лишним ехела незнамо откуда, по гарантии - можно
считать что и не покупали - в дороге проведет свою жизнь :)

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37388; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331988

Ответить   Mon, 13 Dec 2010 18:25:22 +0300 (#1331988)

 

)

продолжение истории...
все оказалось не совсем как думалось сначала
в результате некоторых опытов (монтировал и отмонтировал несколько раз
ФС и смотрел содержимое файлов) выяснилось, что данные на разделе не
запорчены (во всяком случае, в своей основе - что проверилось), а
виновата новая память - при каждом монтировании содержимое файлов
(просмотр в текстовом просмотровщике) менялось случайным образом
(монтировал в режиме только чтение)
т.е. похоже в памяти происходит перехлест страниц, причем не везде, так
как система работает нормально, системные разделы тоже.

тип памяти по документам должен подходить - в список рекомендуемых для
данной материнской платы входит, правда с литерой i на конце ( Intel
Validated), а на сайте kingston наоборот для памяти без i в списке моя
системная плата
тем более скорость памяти выше поддерживаемой материнкой - должно вроде
бы еще надежнее работать

со старой памятью все нормально

ДОС перестал развивать и пошёл в Вин. Теперь memtest поддерживает чипсеты, но
тестируетбесполезно, а testmem хорошо тестирует память, но знает только старые
чипсеты, а вместе-никак.
возможно вопрос не в эту тему - но каким все-же тестом можно обнаружить
перехлесты страниц (областей) памяти? memtest похоже этого не умеет

хотелось бы выяснить точную причину - без нее и память не сдать и новую
не получить

p.s.
кстати sandro был прав:

память на контроллерах (у нас 2 одинаковых сервера) оказалась без ECC
ручки бы пообломать поставщику, да дело очень давнее

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37399; Возраст листа: 2700; Участников: 1367
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1334938

Ответить   Wed, 15 Dec 2010 13:50:31 +0300 (#1334938)

 

12/15/10 1:50 PM, avm7work пишет:

Тогда тем более регулярно проверяйте контрольные суммы на массиве, чтобы
не попасть в мою ситуацию, когда пришлось долго и нудно восстанавливать
7 ТБ покоцанных данных :(

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37401; Возраст листа: 2700; Участников: 1367
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1335109

Ответить   Wed, 15 Dec 2010 15:32:34 +0300 (#1335109)

 

Не зная, как у Вас реализован RAID-5, сложно давать рекомендации. Но
если Вы не делаете хотя бы раз в месяц SCRUBBING этого массива (контроль
и перезапись контрольных сумм), то имеете все шансы в один прекрасный
момент покоцать файлы или файловую систему (например, если у Вас
буферная память контроллера RAID-5 реализована на чипах без контроля
четности, и какая-нибудь ячейка начнет сбоить).

А проверка файловой системы, если никакой диагностики не выдала, ничего
в ФС не делает.

12/10/10 6:42 PM, avm7work пишет:

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37343; Возраст листа: 2695; Участников: 1370
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1328090

Ответить   Fri, 10 Dec 2010 20:54:00 +0300 (#1328090)

 

sandro пишет:

слово не знакомое, не видел такого в меню контроллера и в утилите ОС
это не соответствует consistency?

уверен, что память с ECC, контроллер не дешевый

если это не утилита проверки, тогда сама система (битая новая память?),
потому как структура каталогов и их содержимое и не пострадали, а при
сбое рэйда трудно представить такую избирательность к содержимому файлов.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37378; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331182

Ответить   Mon, 13 Dec 2010 10:02:49 +0300 (#1331182)

 

12/13/10 10:02 AM, avm7work пишет:

Не уверен, что это - одно и то же (впрочем я не знаком с вашим
контроллером). Попробуйте поискать в меню контроллера или утилите нечто,
выполняющее контроль четности данных на массиве (если нет scrubbing, то
это может быть что-нибудь вроде parity check или RAID integrity check)

Все-таки посмотрите на всякий случай. Мне доводилось сталкиваться с
довольно дорогими контроллерами, на которых стояла память без ЕСС.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37380; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331383

Ответить   Mon, 13 Dec 2010 11:44:10 +0300 (#1331383)

 

sandro пишет:

/Не уверен, что это корректная информация, но то что нашел насчет
//Scrubbing//:
Disk Scrubbing/ - в RAID-системах иногда происходит потеря данных -
например, когда к каким-то данным обращаются очень редко, и на этом
месте появляется сбойный сектор; Disk Scrubbing позволяет избежать таких
потерь, - время от времени проверяя состояние всех секторов, и при
первых признаках разрушения восстанавливая информацию с других дисков.
или
A scrubbing function is used to detect and repair corrupt data on one or
more members of the disk array.

и насчет consistency check
http://linux.mkrovlya.ru/book/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-check-consistency

получается эту роль выполняет consistency check
но в любом случае этого не делалось к сожалению

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37381; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331562

Ответить   Mon, 13 Dec 2010 13:29:58 +0300 (#1331562)

 

Тогда попробуйте выполнить consistency check - для проверки целостности
массива. И в дальнейшем возьмите за правило выполнять его (или
Scrubbing) 1 раз в месяц. У меня дисковые массивы делают это автоматом
автономно от компьютера с помощью контроллера. Кстати, эта функция, как
правило, выполняется в фоне и не приводит к снижению продуктивного
быстродействия массива.

Заодно протокол выполнения будет показывать, какие диски в массиве
начинают деградировать (это заметно по количеству BAD BLOCK), чтобы
можно было заранее менять диски, не дожидаясь деградации всего массива.

И еще один момент - у вас S.M.A.R.T. на дисках (которые в массиве)
отключен ? Целый ряд контроллеров требуют это, поскольку сами
контролируют состояние дисков и ремапят их в случае появления сбойных
блоков, а если при этом включен еще и S.M.A.R.T., то может возникнуть
конфликт, последствия которого непредсказуемы.

12/13/10 1:29 PM, avm7work пишет:

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37382; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331634

Ответить   Mon, 13 Dec 2010 14:12:02 +0300 (#1331634)

 

sandro пишет:

Да, нужно упорядочить эти задачи.
В данном случае ошибок не выдал.

А много ли под linux утилит, позволяющих мониторить и управлять
контроллерами raid? Для своего нашел вот varmon, а другие? На сайте
производителя?

smart отключать на самом диске (не в биосе ведь)? hdparm -ом?

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37383; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331747

Ответить   Mon, 13 Dec 2010 15:26:59 +0300 (#1331747)

 

12/13/10 3:26 PM, avm7work пишет:

Честно говоря, не знаю, т.к. у нас внешние массивы со встроенными
контроллерами, которые сервер видит, как один большой диск. Все
управление контроллером идет через Вэб-интерфейс

smart отключается на самом диске. Только вот у меня это делается
настройками самого контроллера.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37384; Возраст листа: 2698; Участников: 1368
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1331841

Ответить   Mon, 13 Dec 2010 16:32:52 +0300 (#1331841)

 

avm7work пишет:

В результате дополнительных тестов и поисков информации все сводится к
тому, что всему виной драйвер (модуль) контроллера raid DAC960 (AcceleRAID).
Во первых потому, что все остальное (на первый взгляд) работает на новой
памяти без проблем, кроме проблем с данными на raid.
Во вторых нашел подтверждение своим мыслям в старом сообщении на одном
сайте:

Старая память как раз 1ГБ, а новая - 4ГБ.
Придется видимо исключить контроллер из работы.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 37496; Возраст листа: 2750; Участников: 1376
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/1405609

Ответить   Thu, 03 Feb 2011 11:29:50 +0300 (#1405609)