Дык а какие там патчи, если дрова качаются с сайта ЛСИЛогик, последние.and3008 писал(а):Ну тогда только смотреть на патчи к XFS или драйверу контроллера. Других чудес не знаю.
ARECA 1260 + 14x750Gb SATA HDD = very big array 9870Gb.
Модераторы: Trinity admin`s, Free-lance moderator`s
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Это Линукс. И не все драйверы бывают одинаково полезны.
Текрамовский контроллер ARECA сделан на чипе одноименной тайванской конторы. Там тоже драйверочки имеются.
Ну если все упирается в 2 ТБ, то баг либо в драйвере, либо в драйвере файловой системы.
Я бы еще автору советовал поставить RHEL или CentOS. C Гентой бывает всякое, как и с Федорой тоже.
Текрамовский контроллер ARECA сделан на чипе одноименной тайванской конторы. Там тоже драйверочки имеются.
Ну если все упирается в 2 ТБ, то баг либо в драйвере, либо в драйвере файловой системы.
Я бы еще автору советовал поставить RHEL или CentOS. C Гентой бывает всякое, как и с Федорой тоже.
Не, ОС - константа.
Ситуация в общем следующая. Как я уже и писал массив удалось разметить на полный объем при помощи parted, указав тип раздела gpt. Потом его отформатировал под xfs, далее перенес (скопировал) на него 1,3Тб информации со старого сервера (больше не было). Перегрузил - диск соответственно не замонтировался, при загрузке вывалилось предложение запустить fsck вручную, я нажал Ctrl-D и отказался. Загрузилась ОС, диск в ауте. Запускаю xfs_repair, поехала процедура проверки массива и поиск суперблоков (именно они не находились при попытке монтирования раздела при загрузке ОС). Запустил утром, не дождался завершения ушел оставив работать, утром смотрю, тест закончен, перегрузился... порядок. Диск виден! Объем 9,8Тб. Сейчас идет его активное тестирование, сервер открыт для доступа по ФТП, который расшарен и в DC++.
Сейчас возникла еще одна проблема, при скачивании по фтп информации и заливке ее на фтп очень низкая скорость по сети. Интерфейсы там гигабитные, а скорость на закачку 10Мбит/сек, скачку 40-50Мбит, т.е. даже не сотка. Интерфейс свитча (DLink 3526 также гигабитный по всей магистрали). Сдается, что это параметры ядра могут влиять. Вопрос какие?
Ситуация в общем следующая. Как я уже и писал массив удалось разметить на полный объем при помощи parted, указав тип раздела gpt. Потом его отформатировал под xfs, далее перенес (скопировал) на него 1,3Тб информации со старого сервера (больше не было). Перегрузил - диск соответственно не замонтировался, при загрузке вывалилось предложение запустить fsck вручную, я нажал Ctrl-D и отказался. Загрузилась ОС, диск в ауте. Запускаю xfs_repair, поехала процедура проверки массива и поиск суперблоков (именно они не находились при попытке монтирования раздела при загрузке ОС). Запустил утром, не дождался завершения ушел оставив работать, утром смотрю, тест закончен, перегрузился... порядок. Диск виден! Объем 9,8Тб. Сейчас идет его активное тестирование, сервер открыт для доступа по ФТП, который расшарен и в DC++.
Сейчас возникла еще одна проблема, при скачивании по фтп информации и заливке ее на фтп очень низкая скорость по сети. Интерфейсы там гигабитные, а скорость на закачку 10Мбит/сек, скачку 40-50Мбит, т.е. даже не сотка. Интерфейс свитча (DLink 3526 также гигабитный по всей магистрали). Сдается, что это параметры ядра могут влиять. Вопрос какие?
Пока что наблюдаю за работой сервера. Так что сделать выводы хорошо или плохо можно будет примерно через неделю.
Про скорость работы сети.
ОС - Gentoo Linux
uname -a: Linux ftp-server 2.6.22-gentoo-r5 #1 SMP Tue Sep 18 13:03:34 MSD 2007 x86_64 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux
lspci | grep net:
06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
один из контрллеров смотрит в Интернет, второй в локальную сеть. "Интернет" контроллер работает на порту свитча в 100Мбит/сек, "локальный" на порту 1000Мбит/сек. Используемый для них драйвер e1000. Вот что пишет dmesg:
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
ПО ftp-сервера: vsftpd: version 2.0.5+ (ext.3.3)
взят с сайта http://vsftpd.devnet.ru/rus/
Причем, при растущем количестве запросов скорость снижается. Я конечно понимаю, что канал не резиновый, но клиенты подключаются по 100Мбит/сек, так что при 10 активных одновременных скачиваниях скорость должна держаться в пределах 100Мбит/сек, это порядка 11-12Мбайт/сек. У нас же ситуация такая, что при подключении 2-х "сосальщиков" скорость режется напополам, а аплоад вообще от 10Мбит/сек и пропорционально едет вниз, такое впечатление, что плата работает в халфдуплексе... Какие методы диагностики сети существуют в Линуксе (может я о чем то не знаю)? Читал про оптимизацию сетевых настроек через sysctl, но после них начались проблемы типа вываливания дампа в консоль и отказ в работе сети.
Пока писал пост нашел 2 статьи: http://www.samag.com/documents/s=8920/s ... /0311a.htm
http://www.opennet.ru/base/net/tcp_tune.txt.html
буду изучать, потом отпишу о результатах.
Про скорость работы сети.
ОС - Gentoo Linux
uname -a: Linux ftp-server 2.6.22-gentoo-r5 #1 SMP Tue Sep 18 13:03:34 MSD 2007 x86_64 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux
lspci | grep net:
06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
один из контрллеров смотрит в Интернет, второй в локальную сеть. "Интернет" контроллер работает на порту свитча в 100Мбит/сек, "локальный" на порту 1000Мбит/сек. Используемый для них драйвер e1000. Вот что пишет dmesg:
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
Код: Выделить всё
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:06:00.0 to 64
e1000: 0000:06:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:30:48:34:72:72
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt 0000:06:00.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:06:00.1 to 64
e1000: 0000:06:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:30:48:34:72:73
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
взят с сайта http://vsftpd.devnet.ru/rus/
Причем, при растущем количестве запросов скорость снижается. Я конечно понимаю, что канал не резиновый, но клиенты подключаются по 100Мбит/сек, так что при 10 активных одновременных скачиваниях скорость должна держаться в пределах 100Мбит/сек, это порядка 11-12Мбайт/сек. У нас же ситуация такая, что при подключении 2-х "сосальщиков" скорость режется напополам, а аплоад вообще от 10Мбит/сек и пропорционально едет вниз, такое впечатление, что плата работает в халфдуплексе... Какие методы диагностики сети существуют в Линуксе (может я о чем то не знаю)? Читал про оптимизацию сетевых настроек через sysctl, но после них начались проблемы типа вываливания дампа в консоль и отказ в работе сети.
Пока писал пост нашел 2 статьи: http://www.samag.com/documents/s=8920/s ... /0311a.htm
http://www.opennet.ru/base/net/tcp_tune.txt.html
буду изучать, потом отпишу о результатах.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 33 гостя