From cd2aaf4bf3c195d45e6ffcd59145decc4e9d7a5f Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Wed, 23 Dec 2020 00:26:56 +0300 Subject: [PATCH] =?utf8?q?=D0=91=D1=8B=D1=81=D1=82=D1=80=D0=BE=D0=B5=20?= =?utf8?q?=D0=B7=D0=B0=D0=BF=D0=BE=D0=BB=D0=BD=D0=B5=D0=BD=D0=B8=D0=B5=20?= =?utf8?q?=D0=B4=D0=B8=D1=81=D0=BA=D0=B0=20=D1=80=D0=B0=D0=BD=D0=B4=D0=BE?= =?utf8?q?=D0=BC=D0=BE=D0=BC?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Если нужно заполнить диск рандомом (перед тем как отдать, сделав заполнение нулями или просто для проверки), то dd if=/dev/urandom делать не стоит для больших скоростей, ибо под FreeBSD используется полноценная Fortuna PRNG, потребление и ротирование энтропии и у меня скорость работы где-то 70-80 MBps, что не может насытить современный SATA диск. Можно использовать (go)hpenc утилиты для генерирования более быстрого рандома, но я делаю проще: # geli onetime -s 4K /dev/disk # dd if=/dev/zero of=/dev/disk.eli bs=1M это конечно не запишет рандом в начало, так как там будет заголовок GELI, но это уже можно "по старинке" перезаписать. При этом по сути всё будет упираться в скорость AES-XTS (по умолчанию), который на современных Intel процессорах и ускоряется ещё (поэтому в CPU не упереться). А рандом будет по всему диску, так как хоть данные и ключ одни и те же, но XTS в качестве tweak-а принимает порядковый номер сектора, который везде будет разный. Вообще и размер GELI сектора можно выставить большего размера, что ещё сократит нагрузку на CPU. -- 2.50.0