urandom & SMP

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

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

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

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

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

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

pupok (03.10.2009 8:46:41):

новое устройство /dev/urandom2 не появится.

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

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

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

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

# cryptsetup -d /dev/random create trash /dev/sda
# pv -c /dev/zero > /dev/mapper/trash

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

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

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

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

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

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

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

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

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

Предлагаю

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

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

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

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

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

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

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

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

Пару раз подряд нулями забить.

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

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

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

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

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

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

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