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
Orientuje się ktoś z jakiego powodu może się powiesić system przy tworzeniu pliku z /dev/zero ? Kernel odpowiada bo można zresetować pc przez sysrq ale po wydaniu
dd if=/dev/zero of=./plik bs=1M count=1000
system w pewnych warunkach pada martwy i nie idzie go dobudzić w żaden sposób.
Ostatnio edytowany przez morfik (2014-01-03 20:36:47)
Offline
Próbuje zapełnić nieskończony dysk twardy.
Offline
Inne jajo.
System może sobie w ten sposób zapchać dyzia, ale nie powinien się zamrażać.
Chyba, że zamarzanie ma swój powód w 100% obciążeniu procka (pomocne mogą być cpulimit, cgroup_cpu), albo zablokowania dyzia przez wyczerpanie limitu operacji IO.
W takim przypadku można pobawić się programikiem ionice albo cgroup_blkio.
Offline
To chyba jednak nie jest problem wykorzystania zasobów.
Zrobiłem sobie taką regułkę:
group users/dd { perm { task { uid = root; gid = root; } admin { uid = root; gid = root; } } blkio { blkio.throttle.write_bps_device = "8:0 5242880"; blkio.throttle.read_bps_device = "8:0 5242880"; } }
8:0 to jest mój główny dysk, a ten 5242880 to 5M zapisu/odczytu max. Podpiąłem to pod dd
*:dd blkio users/dd/ *:dd* blkio users/dd/
i w logu cgrulesengd można przeczytać:
Found matching rule * for PID: 28946, UID: 1000, GID: 1000 Executing rule * for PID 28946... Will move pid 28946 to cgroup 'users/dd/' Adding controller blkio OK! Cgroup change for PID: 28946, UID: 1000, GID: 1000, PROCNAME: /bin/dd OK
A pid widnieje w /cgroup/blkio/users/dd/tasks -- także chyba to działa dobrze. Problem w tym, że to wcale nie ogranicza niczego. :]
$ dd if=/dev/zero of=./zero bs=1M ^C3502+0 records in 3502+0 records out 3672113152 bytes (3.7 GB) copied, 40.466 s, 90.7 MB/s $ dd if=/dev/zero of=./zero bs=1M ^C601+0 records in 601+0 records out 630194176 bytes (630 MB) copied, 8.5338 s, 73.8 MB/s
Znów coś ff jest zamieszany, bo to wieszanie się systemu przy używaniu dd, występuje najczęściej gdy ff jest odpalony.
Offline
Cgroup nie zakłada sztywnych ograniczeń na procek i dysk (tylko w memory można nakładać sztywne limity), zapewnia natomiast, że w czasie maksymalnego obciążenia dany proces będzie trzymany w danym limicie, wylicznym średnią ważoną.
Np w cpu:
Proces 1 - 500
proces 2 - 1000
Przy niskim obciążeniu każdy proces może zająć praktycznie cały procek, ale przy pełnym wykorzystaniu procka dostaną te procesy 1 - 33%, 2 - 66% mocy procka.
To jest dynamiczny podział.
U Ciebie wyraźnie dyzio się nie wyrabia.
Offline
Z czym nie wyrabia? Z kopiowaniem pliku?
To co powyżej było ten 90.7 MB/s przeszedł swobodnie, natomiast pc się przyciął przy 2-5MB/s udało mi się to zobaczyć po paru minutach wciskania ctrl+c. W końcu ubiło proces i wyrzuciło staty dd. Także tutaj coś innego ma znaczenie. Nie wiem co ale jak to dorwę to pewnie rozwiąże wszystkie problemy.
Narazie spróbuję zrobić sobie kopię systemu i wrzucić ja do pliku img i wypalić na drugim dysku, niezaszyfrowanym. Być może tutaj coś jest nie tak z szyfrowaniem.
Offline
Ten problem również został rozwiązany przez dodanie:
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
Więcej info na http://lwn.net/Articles/572911/
Offline
Strony: 1