+- Stresslinux community (https://www.stresslinux.org/community)
+-- Forum: Stresslinux Main (https://www.stresslinux.org/community/forumdisplay.php?fid=1)
+--- Forum: General discussion (https://www.stresslinux.org/community/forumdisplay.php?fid=2)
+--- Thread: Stress FAIL - what do these messages mean? (/showthread.php?tid=185)
Stress FAIL - what do these messages mean? - davidjmcq - 02-18-2013
This may be the wrong forum so please forgive me. I would appreciate anyone pointing me to where I can interpret these messages.
I'm running the program "stress" from the command line of Ubuntu Server 12.04. The command I'm using is:
$ stress --cpu 30 --io 16 --vm 2 --hdd 20 --timeout 1h
I get these messages multiple times:
FAIL: [4653] (584) write failed: No space left on device
and
FAIL: [4599] (397) <-- worker 4603 returned error 1
I get the write failed message even with various parameters much lower. I've also had a kernel panic when running stress as root.
I'm fairly sure that the hardware is buggy, which is why I am running "stress" in the first place
RE: Stress FAIL - what do these messages mean? - stresslinux - 02-23-2013
looks like stress is writing to the ram disk (--hdd 20) of the bootet image.
you should mount a local hard drive(partition) e.g. to /mnt and change to that directory before starting stress, it will create some temporary files in that
directory (default size per file is 1GB), make sure there is enough space, with 20 hdd workers you will need 20GB free space
RE: Stress FAIL - what do these messages mean? - davidjmcq - 02-23-2013
[quote='stresslinux' pid='310' dateline='1361613899']
looks like stress is writing to the ram disk (--hdd 20) of the bootet image.
you should mount a local hard drive(partition) e.g. to /mnt and change to that directory before starting stress, it will create some temporary files in that
directory (default size per file is 1GB), make sure there is enough space, with 20 hdd workers you will need 20GB free space
[/quote]
Thanks.. that explains...
The hardware was indeed buggy and a new motherboard has solved the kernel panic problem. It's good to know how that works for future reference. There simply wasn't enough disk space mounted for what i was trying to do.