Цель "нагрузить 100% процессора" - странная. Замеры нужно проводить не синтетических попугаев, а прикладных метрик - и уже потом пытаться искать узкие места и что-то менять.
Направляете вывод df в grep, который отфильтровывает нужный диск, затем его вывод направляете во что-нибудь, оставляющее только нужные поля, например awk '{print $1, $2}':
Посмотрите внутри скрипта, что там происходит на соответствующем шаге и попробуйте повторить эту команду в консоли.
Предполагаю, что там какой-нибудь wget - и он зависает либо из-за проблем с сетевой связностью, либо что-то с файлом на том конце (не существует и т .п.).
Это не множество процессов - процесс один и тот же. Это активные TCP-сессии. Почему их много - вопрос к приложению, подключающемуся к memcached. Смотрите настройки РНР, имхо.
Можно напрямую, причём даже параллельно несколькими линками (multipath). И один и тот же LUN в разные места - тоже. Естественно, тогда возникает вероятность порчи данных - но это обычно компенсируется со стороны клиентов (они как-то между собой договариваются, что не будут трогать одни и те же объекты одновременно).
Полное шифрование диска - надёжно. При условии, что у клиента не будет доступа внутрь по SSH и консоль. Но тогда встаёт вопрос - как расшифровывать при ребуте? Есть некоторые варианты (1, 2), но они довольно гемороечные.