Вопросы Теги

как получить доступ с Linux к реальной информации о размере блока файловой системы, когда это смонтировано на nfs?

После некоторого более глубокого Расследование, нашел проблему для проблем круглого Робина и Дюп. Они на самом деле связаны.

  • Round Robin (0) вместо активного резервного копирования (1)

на Centos 5+ и, по-видимому, особенно 6.6, он рекомендовал / предпочтительно использовать параметр параметра непосредственно в IFCFG -bond0 (и не в параметрах модуля связывания, что имеет смысл) 

DEVICE=bond0
...
BONDING_OPTS="mode=1 miimon=100"

(режим может быть указан как «1» или как «активное резервное копирование»)
После добавления линии все работало, как ожидалось.

  • Дублированные Ping Кадры

В режиме Round-Robin используются оба интерфейса. И когда интерфейсы соединены с двумя разными коммутаторами, в начале Ping отвечает , могут быть дублированы

, нередко наблюдается короткий взрыв дублированного трафика, когда Устройство связывания впервые используется, или после того, как он был простаивается для некоторых период времени. Это наиболее легко наблюдается, выдавая «пинг» к какой-то другой хост в сети, и замечая, что вывод от пинга Флаги дубликаты (обычно один на раб).

Например, на связи в режиме активного резервного копирования с пятью рабами все Подключен к одному выключателю, выход может появиться следующим образом: 

    # ping -n 10.0.4.2
    PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.
    64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms
    64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)

Это не связано с ошибкой в ​​привязке драйвера, скорее, это Побочный эффект того, сколько выключателей обновляет свои таблицы экспедирования MAC.

После перехода на активный резервную копию больше не наблюдалось никаких дуп.

Это объясняется подробностями в этой неоднозначной освещенной документации

https://www.kernel.org/doc/documentation/networking/bonding.txt

0
20.08.2014, 22:54
1 ответ

Я нашел решение своей проблемы. Это просто математическая проблема! Различные числа могут давать один и тот же результат. Так что между Linux и Solaris, член f_frsize имеет разное значение. Но это не имеет значения, потому что при преобразовании блоков в байты с помощью f_frsize в обеих операционных системах с помощью этой формулы, взятой из here:

static unsigned long kscale(unsigned long b, unsigned long bs)
{
     return (b * (unsigned long long) bs + 1024/2) / 1024;
}

я получил тот же результат, что и при использовании команды df и в обеих операционных системах. Так что нет никакой реальной проблемы, только мое воображение :) Извините.

0
28.01.2020, 04:59

Теги

Похожие вопросы