On Mon, Jun 16, 2003, Yedidyah Bar-David wrote about Re: SOLVED: Slow Linux response
during disk operations (was: Testing on various computers needed):
On Sun, Jun 15, 2003 at 10:13:47PM +0300, Nadav Har'El wrote:
(a while ago I gave on this list, or perhaps hackers-il, an example of
a nasty
On Mon, Jun 16, 2003 at 11:56:01AM +0300, guy keren wrote:
On Mon, 16 Jun 2003, Yedidyah Bar-David wrote:
Sorry for not reading it (apparently wasn't here, maybe hackers-il,
but google doesn't find it), but what I usually do is kill -STOP
all of them, and only then kill
On Sun, Jun 15, 2003 at 09:01:07PM +0300, Beni Cherniavsky wrote:
the system gets completely stuck for a few seconds. Increasing the
number increases the stuck time. Isn't a unix suppossed to protect
users from such DOS attacks in some way (just checked, executing it
from another user has
On Sun, Jun 15, 2003, Beni Cherniavsky wrote about Re: SOLVED: Slow Linux response
during disk operations (was: Testing on various computers needed):
Another question: fork bombs. I think this was much worse a few
years ago but still, when I do::
perl -e 'for $i (1..15) { fork
On Sun, Jun 15, 2003 at 10:13:47PM +0300, Nadav Har'El wrote:
On Sun, Jun 15, 2003, Beni Cherniavsky wrote about Re: SOLVED: Slow Linux response
during disk operations (was: Testing on various computers needed):
Another question: fork bombs. I think this was much worse a few
years ago
On Fri, Jun 13, 2003, Ilya Konstantinov wrote about Re: Testing on various computers
needed:
2. time dd if=/dev/zero of=foo
says:
real0m10.449s
user0m0.260s
sys 0m4.080s
How come real (wall clock) time is so much higher than user+sys combined?
This is simple - the disk can't
On Fri, Jun 13, 2003, Nadav Har'El wrote about Re: Testing on various computers
needed:
On Fri, Jun 13, 2003, Ilya Konstantinov wrote about Re: Testing on various
computers needed:
How come real (wall clock) time is so much higher than user+sys combined?
This is simple - the disk can't
Hello again,
Either most of you don't believe me, or you don't think that a Linux box
getting stuck is so serious.
I have gotten some responses, some in private, with the same
experiences. Someone mentioned going to a coffee break when a large file
is being untarred (I do the same). And I ask
Hello again,
As usual, it's me answering my own questions.
The very slow perfomance of the hard disk under Linux caused me to
reconsider the DMA issue again. I also found that others have been
discussing this:
All my file servers at work (and at home) are Linux based... some are
even using the same RH version you are using (7.3). (I'm too lazy to
reboot them in-order to upgrade them to 9.0...)
Moving GB size files is something I do on a daily basis and I've yet to
see what you describe. (And my main
I'm not saying that you're wrong, I am saying that before you start a
'Linux sucks' advocacy thread, one would suggest that you start by
reading more about the IDE controller that you are using (Intel
chipset?) and the kernel support it has in 2.4.18.
Suppose that upgrading the kernel will
On Fri, Jun 13, 2003 at 01:36:51PM +0200, Eli Billauer wrote:
Hello again,
Either most of you don't believe me, or you don't think that a Linux box
getting stuck is so serious.
I have gotten some responses, some in private, with the same
experiences. Someone mentioned going to a coffee
Hello all,
I have addressed this issue in the past, but never got to really solve
this. And it's annoying me again.
I'm running RH7.3, with a 2.4.18-3 from-the-box kernel, which in my
opinion doesn't meet a basic requirement to be called a multi-user or
multitask OS.
The thing is, that when
Hi,
I just tried it. It happens here as well. I have Mandrake 9.1, kernel
2.4.21.
Moshe
+ Eli Billauer [EMAIL PROTECTED] [12/06/03 22:17]:
Hello all,
I have addressed this issue in the past, but never got to really solve
this. And it's annoying me again.
I'm running RH7.3, with a
are you trying it on the same disk your system is on?
couldn't it just be the fact reading becomes much slower when write into
the disk like that?
btw you forgot to mention what sort of file system type it is
I guess journaling file systems would behave diffrently from those which
isn't? not sure
Ely Levy wrote:
are you trying it on the same disk your system is on?
couldn't it just be the fact reading becomes much slower when write into
the disk like that?
Even if that was true, it's no excuse to get stuck.
And no, it's not the reading getting slower. I'm talking about slow echo
+ Ely Levy [EMAIL PROTECTED] [13/06/03 00:59]:
are you trying it on the same disk your system is on?
Yes
couldn't it just be the fact reading becomes much slower when write
into
the disk like that?
I guess Eli would say it's not supposed to happen either.
btw you forgot to mention what
On Fri, Jun 13, 2003 at 01:04:32AM +0200, Eli Billauer wrote:
Ely Levy wrote:
are you trying it on the same disk your system is on?
couldn't it just be the fact reading becomes much slower when write into
the disk like that?
Even if that was true, it's no excuse to get stuck.
And
What CPU (and other hardware) do you have?
Modern and fast IDE disks, with their (comparatively) primitive
controller, cause high CPU load.
I'm with a 1.7 GHz Celeron on an Intel motherboard. 256MB of RAM, almost
never swapping. A rather new hard disk.
But even if the IDE controller is a
On Thursday 12 June 2003 22:41, Eli Billauer wrote:
The thing is, that when I go (as a simple user, not root)
cat /dev/zero /junk/junkfile
the system responds very slowly after a couple of seconds, even to the
root user. The file grows quickly, yes, but I don't think that any
multiuser
20 matches
Mail list logo
