Я хочу зашифровать и расшифровать большие файлы (примерно 20 миллионов строк) текста. Служба шифрования, которую я использую, может шифровать только максимальный размер 64 КБ. Для целей этого вопроса предположим, что мы застряли с этим сервисом.
Мое решение состоит в том, чтобы разбить огромный файл на куски по 64 КБ, зашифровать их все параллельно и поместить зашифрованные части в tar.gz
. Каждая часть пронумерована как part-xxx
, чтобы убедиться, что я могу восстановить исходный файл. Во время расшифровки я распаковываю, расшифровываю каждую часть параллельно и сопоставляю результаты по порядку.
Самое интересное: когда я делаю эту последнюю часть над достаточно большим файлом, происходит одно из следующих действий:
Сеансы tmux умирают, и я выхожу из системы. Нет журналов, нет ничего.
Я получаю это:
/home/estergiadis/kms/decrypt.sh: line 45: /usr/bin/find: Argument list too long
/home/estergiadis/kms/decrypt.sh: line 46: /bin/rm: Argument list too long
Я попробовал несколько решений, основанных на xargs, но безуспешно. Вот интересный код:
echo "Decrypting chunks in parallel."
# -1 -f in ls helped me go from scenario 1 to scenario 2 above.
# Makes sense since I don't need sorting at this stage.
ls -1 -f part-* | xargs -I % -P 32 bash -c "gcloud kms decrypt --ciphertext-file % --plaintext-file ${OUTPUT}.%"
# Best case scenario, we die here
find $OUTPUT.part-* | xargs cat > $OUTPUT
rm $OUTPUT.part-*
Еще интереснее: когда find и rm сообщают о проблеме, я могу go во временную папку со всеми частями, выполнить те же самые команды сам и все работает.
В случае, если это имеет значение, все это происходит в файловой системе, смонтированной в ОЗУ. Однако проблема с ОЗУ не может быть: я на машине с 256 ГБ ОЗУ, файлы занимают 1-2 ГБ, а htop
никогда не показывает более 10% использования.