zuborg

Скорее всего у Вас label битый, со слайсом размером в 180Г на винте меньшего размера, либо с началом слайса большим чем надо. Итого gpart детектит по таблице bsdlabel слайс обьемом 180Г и создает блочное устройство с соотв характеристиками. А запросы dd проходят к физическому диску и доходят до его конца раньше, чем достигнут конца слайса.

Размер потерь на место — это приблизительно 1/2 * размер блока (для некоторых FS — фрагмента блока, как в UFS) * кол-во файлов (+папок) + оверхед FS * кол-во блоков.
Исходя из первого слагаемого — блоки надо делать как можно меньше, а из второго — как можно больше (тогда блоков будет меньше).
Первое слагаемое можно оценить непосредственно (`df -i` в помощь), второе — оценить, сравнив полное место согласно выводу команды df с собствено размером диска (раздела), обычно разница порядка несколько процентов. В идеале оба слагаемых должны быть приблизительно равны.

Строго говоря, ответ «snmp» просто меняет протокол доступа к информации с ssh на более простой и пригодный для большого кол-ва машин.

Но вообще для массового мониторинга все равно надо либо опрашивать все сервера (через ssh, snmp, http, свой вариант), либо настроить чтобы сервера сами отсылали уведомления на центральный сервер (syslog, mail, опять же ssh, http, snmpv3 или что-то свое).

Вариантов много, у каждого свои преимущества и недостатки. Например, опрашивать сервера по snmp и строить rrd на одном сервере очень удобно и нормально когда их меньше сотни, а на тысячу серверов одного центрального будет не достаточно (либо он должен быть действительно мощным, особенно касательно скорости дисков).

# grep -Rh '#include'. | sort | uniq -c | sort -n
Всякие библиотеки требуют соотв строчки #include чтобы импортировать функции, константы, макросы и прочее от библиотеки.

Узнать откуда ставить соотв .h файл зависит от ОС, возможно поможет whereis или locate. Ну или гугл.