GoogleCodeExporter
commented
9 years ago It's unlikely this is an iperf3 problem.
There's not a lot of evidence here, particularly given the magnitude
of the issue that's being claimed.
In particular, we don't know how iperf3 was being run (client and
server command line arguments, superuser permissions or lack thereof,
and so on). We don't know if during the "wait a week" part of the bug
report iperf3 was continuously running or if it had just been run a
few times. We don't know if it was the client or server side that had
problems.
Nevertheless, a few technical points:
1. If it was being run as an ordinary user (i.e. not root) iperf3
wouldn't even have the permissions to cause any damage to the
filesystem. Note that iperf3 does *not* require superuser privileges
to run, in its default configuration. The only reasons I can think of
for needing to be run as root would be if iperf3 needed to bind to a
low-numbered TCP port or if one of its options (such as -F or -I)
needed to read or write to a protected directory.
2. In its default mode of operation, iperf3 creates (to the best of
my knowledge) exactly one file, in /tmp, which is used for a
memory-mapped file. This file creation cannot under any reasonable
set of circumstances cause a system to be unbootable.
3. I personally have run iperf3 on OS X as a part of development and
testing, on multiple machines (both 10.8 and 10.9), over the past
three months. They have all survived without any issues like those
described here. I know for a fact that iperf3 has been used by others
on OS X systems yet nobody else has reported this problem.
Given the lack of detail in the bug report, plus the points above,
it's extremely hard to connect iperf3 with the reported filesystem
corruption. It's much more likely that it was caused by something
else.
Closing as invalid.
Original comment by bmah@es.net on 27 Feb 2014 at 6:39
- Changed state: Invalid
Original issue reported on code.google.com by
b...@mansubi.comon 27 Feb 2014 at 3:28