Мне кажется тут горлышко в проце.

SATA II, 7200

тут горлышко в шине, если механика даст шину загрузить вообще. Чтение не только линейное бывает. Шифровка\дешифровка на проце происходит, уже после шины, так что нет, полное шифрование в этом случае повлиять не может.

kogoth, Jameson, благодарю.

Никакого, конечно, диск же медленный.

Тут я спрашивал то же самое, но про SSD: Оверхед при шифровании /home на SSD

Я потом тестировал скорость зашифрованных SSD MVMe и SATA 3 на двух финкпадах, разница получилась на уровне погрешности относительно незашифрованного носителя.

Благодарю.

Нет разницы

Разницы нет. Тем более, что для шифрования в прочессорах давно уже специальные наборы инструкций, которые позволяют шифровать очень быстро и не особо затратно в плане искричества.

что для шифрования в прочессорах давно уже специальные наборы инструкций

Так-то да, только

SATA II, 7200 оборотов

SATA III появилась раньше, так что далеко не факт, что у ТС они есть.

Внедисковое шифрование

Я про шифрование силами опенсорных инструментов работающих на ЦоПе, а не мутными зыкрытыми шифровальными приблудами контроллеров НЖМД.

Так и я про ЦП. Если у ТС дисковая подсистема на SATA II, то откуда у него проц с криптографией? Ведь SATA III появилась раньше процов с криптографией.

ЦП AMD Athlon II X4 620.

Ну вот, то есть никакого аппаратного ускорения шифрования нету, да и производительность проца так себе, особенно в однопотоке, на шифровании возможны заметные просадки.

Ведьмака не слушай, у него i7 с аппаратным шифрованием, это совсем другая история.

То есть, выходит что лучше использовать криптоконтейнеры, или разделы отдельно шифровать и монтировать при надобности?

Изначально хотел зашифровать полностью весь диск, swap, при установке ОС.

Я для себя решил вопрос в пользу KDE Vaults. А так, можешь попробовать разные варианты и решить. Когда есть аппаратное шифрование, действительно, можно рассматривать вариант полного шифрования, потому что оно фактически бесплатно. Хотя я и не вижу смысла шифровать /bin/bash и прочее, потому и выбрал для себя такое решение, как Vaults.

Благодарю, а можно где-то почитать более точные замеры снижения производительности HDD при шифровании? Что бы примерно иметь представление, насколько сильное влияние будет.

Ну, во-первых, глянь cryptsetup benchmark, чтобы посмотреть, насколько всё плохо конкретно у тебя. Во-вторых, точно сказать затруднительно. зависит от многих факторов, в том числе и от характера дисковых нагрузок.

Чо это не слушай? Я ему ссылку дал на тред не просто так, там в комментариях показали как бенчить. Если он не стал читать, то ССЗБ.

Всё равно быстро

У меня был полностью зашифрованный НЖМД (кроме /boot, но включая swap) с одноядерным Athlon’ом XP 3000✚. На глаз просадок производительности не заметил.

Athlon FX 3000+? У меня такой же был в 2005.

Учитывая скорость его старого винта, я бы тоже поставил, что никаких просадок даже близко не будет. Но побенчить всё равно стоит.

Результаты

# Тесты, использующие практически только память (без ввода-вывода на хранилище).
PBKDF2-sha1       656180 итераций в секунду для 256-битного ключа
PBKDF2-sha256     807839 итераций в секунду для 256-битного ключа
PBKDF2-sha512     305885 итераций в секунду для 256-битного ключа
PBKDF2-ripemd160  453536 итераций в секунду для 256-битного ключа
PBKDF2-whirlpool  193036 итераций в секунду для 256-битного ключа
argon2i       4 итераций, 671961 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)
argon2id      4 итераций, 672278 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)
#     Algorithm |       Key |      Encryption |      Decryption
#      Алгоритм |      Ключ |      Шифрование |     Расшифровка
        aes-cbc        128b       138,3 MiB/s       165,7 MiB/s
    serpent-cbc        128b        56,5 MiB/s       165,1 MiB/s
    twofish-cbc        128b       135,7 MiB/s       170,3 MiB/s
        aes-cbc        256b       121,3 MiB/s       128,3 MiB/s
    serpent-cbc        256b        66,2 MiB/s       164,7 MiB/s
    twofish-cbc        256b       143,2 MiB/s       170,3 MiB/s
        aes-xts        256b       145,5 MiB/s       167,9 MiB/s
    serpent-xts        256b       139,3 MiB/s       156,3 MiB/s
    twofish-xts        256b       156,0 MiB/s       162,8 MiB/s
        aes-xts        512b       129,6 MiB/s       131,4 MiB/s
    serpent-xts        512b       154,5 MiB/s       156,4 MiB/s
    twofish-xts        512b       164,4 MiB/s       163,4 MiB/s

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

Загрузку ЦП во время теста ещё посмотри.

Но скорости с небольшим запасом хватает, по-моему. Редкие крутые винты 200мб в секунду умеют, а обычно чуть более 100.

Чисто на ввод/вывод —- хватает. Но это же бенчмарки пиковой скорости шифрования, со 100% задействованием процессора. Т.е. на активном вводе/выводе системе будет плоховато.

Ради интереса проверил ещё просто скорость чтения/записи

riniko@windows:~$ sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 16,2821 s, 65,9 MB/s
riniko@windows:~$ sudo /sbin/sysctl -w vm.drop_caches=3
[sudo] пароль для riniko: 
vm.drop_caches = 3
riniko@windows:~$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 15,7428 s, 68,2 MB/s

Не забывай, что у тебя-то шифрование хардварное, практически бесплатное (выполняется на отдельном блоке, конкурирует только за кэш и место в конвейере, но не за вычислительные блоки), а тут всё будет с обычными процессами конкурировать.

WitcherGeralt, gremlin_the_red, да, на этом пункте все ядра под 100%

PBKDF2-sha1       688041 итераций в секунду для 256-битного ключа
PBKDF2-sha256     848362 итераций в секунду для 256-битного ключа
PBKDF2-sha512     319298 итераций в секунду для 256-битного ключа
PBKDF2-ripemd160  469792 итераций в секунду для 256-битного ключа
PBKDF2-whirlpool  193321 итераций в секунду для 256-битного ключа
argon2i       4 итераций, 712128 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)
argon2id      4 итераций, 717080 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)

На этом 1 ядро под 100%

#     Algorithm |       Key |      Encryption |      Decryption
#      Алгоритм |      Ключ |      Шифрование |     Расшифровка
        aes-cbc        128b       150,7 MiB/s       163,7 MiB/s
    serpent-cbc        128b        65,9 MiB/s       164,2 MiB/s
    twofish-cbc        128b       142,3 MiB/s       169,0 MiB/s
        aes-cbc        256b       120,5 MiB/s       127,8 MiB/s
    serpent-cbc        256b        66,0 MiB/s       164,3 MiB/s
    twofish-cbc        256b       142,3 MiB/s       168,9 MiB/s
        aes-xts        256b       167,1 MiB/s       167,8 MiB/s
    serpent-xts        256b       154,2 MiB/s       156,1 MiB/s
    twofish-xts        256b       163,5 MiB/s       161,8 MiB/s
        aes-xts        512b       130,4 MiB/s       131,1 MiB/s
    serpent-xts        512b       154,1 MiB/s       155,4 MiB/s
    twofish-xts        512b       163,2 MiB/s       161,8 MiB/s

Чтобы не теоретизировать, создай криптоконтейнер на loop-устройстве да проверь скорость чтения/записи на него, а также загрузку процессора.

Ага, я в курсе.

Хорошо, с криптоконтейнерами средствами линукс мало опыта было, потому какие команды выполнять для создания и проверки скорости чтения/записи?

Это же не ноутбук?

На десктопе, имхо, не критично. А вот на ноуте 50% ядра (на 60-70мб/с) на чтение это нехорошо.

Не ноутбук, но загрузка 1 ядра на 100% как-то не очень хорошо же. Особенно учитывая что частота ядер не самая высокая, и их вполне себе ютуб неплохо может нагрузить, все 4.

Считаем, что сидим под рутом

mkdir test && cd test
dd if=/dev/zero of=test.img bs=1M count=1024
losetup /dev/loop0 test.img
cryptsetup luksFormat /dev/loop0
cryptsetup luksOpen /dev/loop0 test
mkfs.ext4 /dev/mapper/test
mkdir testmnt
mount /dev/mapper/test ./testmnt
dd if=/path/to/some/big/file oflag=direct of=./testmnt/test.dat bs=1M

Так 100% и не будет, учитывая скорость твоего винта, и то не перманентно, а только при чтении и записи короткими пиками. Лучше всего, наверное, разница будет видна при запуске Eclipse или IDEA.

Вот первая попавшаяся инструкция адекватная на первый взгляд: https://www.digitalocean.com/community/tutorials/how-to-use-dm-crypt-to-create-an-encrypted-volume-on-an-ubuntu-vps

Краткая последовательность действий: создаёшь файл — будущий образ файловой системы — желаемого размера, затем создаёшь в нём контейнер с помощью cryptsetup, затем открываешь его, получая девайс-маппер, затем создаёшь там фс и монтируешь.

Можешь положить туда тот же эклипс и рядом просто в нешифрованное пространство, да убедиться лично на глаз, стал тормозить запуск или нет.

Чёрт, опередил, пока я инструкцию искал.

Разницы на скоростях Sata II нет, но вообще — есть.

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

В статье рассказывается о влиянии LUKS на скорость и задержку в I/O-операциях, а также приведены тесты.

В статье рассказывается про чисто программное шифрование, как у ТС с его низкочастотным атлоном 10-летней давности?

Где тут туплю?

riniko@windows:~/test$ sudo dd if=/dev/zero of=test.img bs=1M count=1024
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 6,03781 s, 178 MB/s
riniko@windows:~/test$ sudo dd if=/dev/zero of=test.img bs=1M count=1024
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 15,424 s, 69,6 MB/s
riniko@windows:~/test$ sudo cryptsetup luksFormat /dev/loop0
Устройство /dev/loop0 не существует или отказано в доступе.

Я вижу два раза dd и ни одного losetup

Как-то так. Правильно всё? При создании криптоконтейнера была нагрузка до 100% на все ядра. При чтении «большого файла», до 85% примерно на все ядра.

riniko@windows:~$ sudo mkdir test && cd test
riniko@windows:~/test$ sudo dd if=/dev/zero of=test.img bs=1M count=1024
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 6,42012 s, 167 MB/s
riniko@windows:~/test$ sudo losetup /dev/loop0 test.img
riniko@windows:~/test$ sudo cryptsetup luksFormat /dev/loop0

WARNING!
========
Данные на /dev/loop0 будут перезаписаны без возможности восстановления.

Are you sure? (Type uppercase yes): YES
Введите парольную фразу для /dev/loop0: 
Парольная фраза повторно: 
riniko@windows:~/test$ sudo cryptsetup luksOpen /dev/loop0 test
Введите парольную фразу для /dev/loop0: 
riniko@windows:~/test$ sudo mkfs.ext4 /dev/mapper/test
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 258048 4k blocks and 64512 inodes
Filesystem UUID: fd45c13a-ff32-4f47-bca7-655e2526a71e
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

riniko@windows:~/test$ sudo mkdir testmnt
riniko@windows:~/test$ sudo mount /dev/mapper/test ./testmnt
riniko@windows:~/test$ sudo dd if=//media/riniko/01D5C3B04AD5BE80/download/debian-live-10.5.0-amd64-xfce.iso oflag=direct of=./testmnt/test.dat bs=1M
dd: ошибка записи './testmnt/test.dat': На устройстве не осталось свободного места
958+0 записей получено
957+0 записей отправлено
1003487232 байт (1,0 GB, 957 MiB) скопирован, 27,5958 s, 36,4 MB/s

Лишние 3-5 секунд на запуске тяжёлого приложения, не сильно важны. Интересно скорее при использовании торрентов, аудио и видео файлов.

Серьёзно? Какие торренты? Зачем тебе шифрование тогда?

dd if=//media/riniko/01D5C3B04AD5BE80/download/debian-live-10.5.0-amd64-xfce.iso oflag=direct of=./testmnt/test.dat bs=1M

Неправильно тестишь. Ты же пишешь и читаешь с диска одновременно.

Или то другой диск?

Лучше бы нулями или чем-то из tmpfs забивал.

При чтении «большого файла», до 85% примерно на все ядра

36,4 MB/s

Собственно, это приговор. Работать на такой системе будет невозможно. Шифруй исключительно чувствительные данные. если без этого никак.

От там торренты в фоне качать собрался на шифрованны носитель. Что в принципе не логично, а в данном случае безумие.

WitcherGeralt, хотел и шифровать данные, и использовать так как всегда. То есть, когда при установке в меню разметки, дистрибутив предлагает полностью зашифровать всё, Debian например. А не как например Ubuntu - только /home. Про диск, как gremlin_the_red указал, так и писал. Диск один.

gremlin_the_red, благодарю.

Если диск один, то скорость ты неправильно померил. Померив правильно, получишь ту же скорость, что и без шифрования

Но с торрениами всё равно жопа будет. Это же постоянные чтение и запись.

Без шифрования с диска на тот же диск на сата 2 буде от 50 до 70 мб/с, если. конечно, файл не слишком фрагментирован. Я проверял.

Каким чудом? У него чтение и запись чуть больше 60 без шифрования, он выше показывал. С чего бы одновременно это работало с той же скоростью?

Как померить правильно?

Писал же выше.

Но стоит только из интереса. Торренты вкупе шифрованием всё равно тебе проц нагибать будут.