Вопросы Теги

Дублируйте stdin в stdout и stderr, но синхронно

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

Я проявил другой подход; вместо того, чтобы делать один большой RAID, я разделил свои диски и создал несколько меньших (например, 8x 250G разделы на диске на 2 ТБ). Это означает 8 НАБЕГОВ вместо 1, 8 контейнеров LUKS, и LVM скрепляет все это вместе в одном большом VG.

Затем, пока у Вас есть процессы, работающие в различных областях диска, различные контейнеры LUKS и НАБЕГИ работали бы друг независимо от друга. Это не истинное параллельное шифрование (ядро все еще не поддерживает это самостоятельно?), но это работало действительно хорошо на меня.

Я имел в наличии ту установку даже на моем новом поле Haswell, где шифрование не является проблемой вообще благодаря AES-NI. Я сделал это, потому что существуют другие эффекты положительной стороны. Например, единственный поврежденный сектор заставил бы только 250G часть диска выпадать из RAID, в то время как другой 1750G остаются избыточными; или если существует ошибка как паника ядра RAID5 в 3.13.0, только один из НАБЕГОВ должен повторно синхронизировать вместо всех них.

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

2
06.09.2015, 15:06
2 ответа

Нет общего способа достичь того, что вы хотите.

Основная проблема в том, что труба - это односторонняя вещь, и производитель не имеет абсолютно никаких знаний о текущем состоянии потребителя, и о том, были ли данные, отправленные в трубу, уже потреблены или нет.

Итак, есть два способа обойти это ограничение, и оба требуют априорных знаний о данных и потребителях:

  • вы делаете производство (или транспортировку от оригинального производителя к трубам потребителей) настолько медленным, что потребители всегда синхронизированы, т.е. после каждой строки, которая должна быть отправлена на потребление, вы ждете так долго, что потребители на 100% уверены, что уже закончили обработку к тому времени, когда будет отправлена следующая строка (что-то похожее на то, что предложил TiberiusKirk),

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

Первый обходной путь требует надлежащей нижней границы для оценки времени обработки входных данных, второй обходной путь требует некоторой обратной связи от потребителей.

3
27.01.2020, 22:05

Может быть, вы можете замедлить чтение файла, заставив тем самым более быстрого потребителя ждать? 

while read LINE; do
   echo "$LINE" | tee /dev/stderr | ./consumer1.py ; ) 2>&1 | ./consumer2.py
   sleep 0.01
done < "file.txt"

Однако в некоторых системах режим сна менее 1 секунды не подходит.

0
27.01.2020, 22:05

Теги

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