LINUX.ORG.RU

urandom & SMP


0

0

заметил что если запустить

# pv -c /dev/urandom > /dev/sda

то одно из ядер CPU загружается на 100%, а второе в генерации псевдо-случайного потока не используется вообще. Можно ли как-то задействовать оба ядра, а то так мне больше суток придётся ждать пока потрётся весь диск?

★★

Хм. А ты уверен, что скорость записи на диск выше скорости генерации потока?

GotF ★★★★★
()
Ответ на: комментарий от GotF

> А ты уверен, что скорость записи на диск выше скорости генерации потока?

100% уверен, /dev/urandom читается со скоротью 7MB/sec -- /dev/zero пишется на диск гораздо быстрее.

pupok ★★
() автор топика
Ответ на: комментарий от pupok

В принципе, это тупость, но могу предложить распилить диск на два равных раздела и пустить два процесса - по одному на раздел. Проверить не могу, но, думаю, должно работать.

GotF ★★★★★
()
Ответ на: комментарий от GotF

> распилить диск на два равных раздела и пустить два процесса

вопрос не в диске, а в том как заставить оба ядра участвовать в генерации /dev/urandom. От того что запустишь второй поток записи на диск -- новое устройство /dev/urandom2 не появится. Там скорее всего какой-то потоковый шифровальщик используется (грубо говоря берут /dev/zero -- шифруют -- получается /dev/urandom), надо чтобы этот шифровальщик работал в несколько потоков чтобы все ядра задействовать.

pupok ★★
() автор топика
Ответ на: комментарий от GotF

> Можно создать ещё одно. man urandom.

в моём man urandom ничего про urandom2 не говорится. В общем пока что сделал

# cryptsetup -d /dev/random create trash /dev/sda
# pv -c /dev/zero > /dev/mapper/trash
так тоже всё равно только одно ядро используется, но скорость терпимая. И при желании действительно можно для разных частей диска запустить несколько потоков.

pupok ★★
() автор топика
Ответ на: комментарий от Lumi

> Не надо man urandom, надо man shred.

в shred ничего про качественный источник случайных данных не говорится, там больше заботятся как переписать байтики в конкретном файле. У меня такой проблемы нет -- переписать надо весь /dev/sda :)

pupok ★★
() автор топика

Многопоточность впихнули в bash?

gh0stwizard ★★★★★
()
Ответ на: комментарий от pupok

что вы такое гоните!?

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

философы блин.

scaldov ★★
()
Ответ на: комментарий от scaldov

только вам это не поможет -- dd (или что у вас там) не многопоточен, а разные части диска забивать -- у винта головы будут летать, что даст эпические тормоза.

предлагаю пропатчить dd чтоб была опция if2= ☺

scaldov ★★
()
Ответ на: комментарий от scaldov

Зачем? Надо ведь случайные данные, если они перемешаются, никто не обидится.

Предлагаю

(taskset 1 cat /dev/urandom & taskset 2 cat /dev/urandom) | dd of=file

lodin ★★★★
()
Ответ на: комментарий от lodin

вот, похоже действительно то что надо, спасибо

# (taskset 1 cat /dev/urandom & taskset 2 cat /dev/urandom) | pv -c > /dev/sda

pupok ★★
() автор топика

> то одно из ядер CPU загружается на 100%, а второе в генерации псевдо-случайного потока не используется вообще. Можно ли как-то задействовать оба ядра, а то так мне больше суток придётся ждать пока потрётся весь диск?

Кто ж трёт диск медленным ~4MB/s устройством? достаточно /dev/zero, либо самописный генератора рандомных блоков, который выдаст 200-1500MB/s, чего зватит для линейной записи на диск (~100MB/s)

Adjkru ★★★★★
()

А нулями забить не вариант?

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

я не стираю информацию которая уже есть на диске, я подготавливаю диск для того чтобы писать на него информацию. Если на диске который забит из /dev/urandom завести dm-crypt контейнер -- то невозможно будет не только прочитать информацию из контейнера, но и вообще узнать сколько там её и в каких секторах она живёт.

pupok ★★
() автор топика
Ответ на: комментарий от pupok

Так бы сразу и сказал, я бы тогда шредер не стал бы предлагать.

Lumi ★★★★★
()
Ответ на: комментарий от pupok

>> Кто ж трёт диск медленным ~4MB/s устройством?

> мы, параноики :)


хз, по-моему это все равно что использовать рабский труд вместо погрузчика :)

/dev/urandom не безопаснее самописного генератора блоков, или адаптированного, например ISAAC (он криптографически стойкий вроде тоже)

Adjkru ★★★★★
()
Ответ на: комментарий от pupok

Настоящим параноикам нужен /dev/random, а не /dev/urandom.

GotF ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.