Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Otóż tak, jest sobie /dev/urandom ale jego wydajność u mnie jest na poziomie 4M/s przy ustawieniu jako źródło w programie dd. /dev/zero posiada wielokrotnie większą wydajność tylko, że generuje same zera.
Czy zna ktoś sposób na to aby plik np. o wielkości 100M podmontować tak aby dd traktowało go jak nieskończoną ilość danych (w tym przypadku wielokrotność pliku 100M, a więc co 100M dane by się powtarzały). Chodzi o zwiększenie wydajności zapisu danymi pseudolosowymi dużych powierzchni, jestem w stanie zaakceptować to aby bloki miały np. po 100M.
Offline
Po prostu za drugim razem, to znaczy po zapisaniu pierwszych 100M, trzeba "przeskoczyć" te 100M pliku wyjściowego, potem 200M, itd. [b]Przykład, nie testowany ;-)[/b]
dd if=plik_1024 bs=1024 of=plik_wyj
dd if=plik_1024 bs=1024 seek=1 of=plik_wyj
dd if=plik_1024 bs=1024 seek=2 of=plik_wyj
...
dd if=plik_1024 bs=1024 seek=n of=plik_wyj
itd.[/quote]
Zobacz w pomocy do dd opcje ibs, obs, bs, seek
Offline
Jaki poziom losowości zapewniają dane które powtarzają się co każde 100 MB?
Offline
Wydajność [i]/dev/random[/i] zależy od aktualnej entropii systemu, a ta z kolei od wielu innych czynników. Generalnie skomplikowana sprawa ;) Zamiast [i]/dev/random[/i] możesz użyć [i]/dev/urandom[/i] które zapewnia o wiele większą wydajność, lecz dane nie są już tak bardzo losowe, więc nie w każdym przypadku można tego użyć.
Jest jeszcze coś takiego jak [i]rng-tools[/i] - dostarcza demona który "miesza" dane ze sprzętowego generatora liczb losowych i pseudolosowych z kernela, przez co wydajność [i]/dev/random[/i] znacząco się zwiększa, a losowość jest na akceptowalnym poziomie. Przetestuj, a nuż Ci się przyda ;)
Offline
Jeśli wejściowy plik będzie tworzony z /dev/urandom, po powtarzanie go w blokach po 100 MB będzie wystarczające do większości amatorskich zastosowań. Można też utworzyć wiele sampli i wybierać je losowo przy kolejnym dopisywaniu, kwestia pomysłowości przy pisaniu skryptu.
Offline
[b]andreq[/b]: w amatorskich rozwiązaniach wystarczy dane nadpisać [tt]/dev/zero[/tt]. Albo jeśli chodzi o dane naprawdę wrażliwe, to zazwyczaj jest ich na tyle mało (w porywach kilka gigabajtów, choć zazwyczaj nie sięgają nawet kilkuset megabajtów), że odpowiednie bloki można kilkukrotnie nadpisać danymi z binarnych plików systemowych. A resztę /dev/zero.
Offline
Założyciel wątku napisał:
Chodzi o zwiększenie wydajności zapisu danymi pseudolosowymi dużych powierzchni, jestem w stanie zaakceptować to aby bloki miały np. po 100M[/quote]
Więc widocznie zależy mu na wydajności, może ma do nadpisania całą szafę 42U z macierzami... ;-)
Offline
[url=http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS]Kilka ciekawostek[/url] Tam napisali kilka słów na tema "łajpałt" :)
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00011 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00095 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.129.63.252' WHERE u.id=1 |
0.00067 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.129.63.252', 1732328777) |
0.00049 | SELECT * FROM punbb_online WHERE logged<1732328477 |
0.00064 | DELETE FROM punbb_online WHERE ident='3.145.61.199' |
0.00077 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=17489 AND t.moved_to IS NULL |
0.00005 | SELECT search_for, replace_with FROM punbb_censoring |
0.00163 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=17489 ORDER BY p.id LIMIT 0,25 |
0.00068 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=17489 |
Total query time: 0.00603 s |