I need to copy large (> 100GB) files between machines on a fast
network. Both machines have reasonably fast disk subsystems, with
read/write performance benchmarked at > 800 MB/sec. Using 10GigE cards
and the usual tweaks to tcp_rmem etc., I am getting single-stream TCP
throughput better than 600
I am using Linux 2.6.16.46-0.12-smp (SUSE 10 SP1 stock kernel).
I do intend to bother SUSE, but I am hoping some kind kernel savant
can help me interpret these log messages and/or give me some
suggestions for how to proceed.
My system is a SunFire x4100 (x86_64) with 16G of RAM and 32G of swap
in
Theodore Ts'o <[EMAIL PROTECTED]> writes:
> With a properly set up set of init scripts, /dev/random is
> initialized with seed material for all but the initial boot
What about CD-ROM based distros (e.g., Knoppix), where every boot is
the initial boot?
> (and even that problem can be solved by ha
Trond Myklebust <[EMAIL PROTECTED]> writes:
> What filesystem are you exporting?
Just ext2; all of our file systems are ext2.
The disks here are a mixture of IDE, SCSI (aic7xxx and sym53c8xx), and
Mylex DAC960 RAID. In this case, the machine running 2.2.18 has
aic7xxx SCSI. I suspect I could
Igmar Palsenberg <[EMAIL PROTECTED]> writes:
> On 23 Oct 2000, Patrick J. LoPresti wrote:
>
> > Not true. The named on our loghost is authoritative for the reverse
> > mappings for all of the machines which can log there.
>
> Put the names of your machines in
Ricky Beam <[EMAIL PROTECTED]> writes:
> Personally, I'd look closely at your setup to determine exactly why
> this has become a problem. named is being blocked on writing to
> /dev/log. This should only happen if there is sufficient _local_
> syslog traffic to fill the buffer or syslogd has to
Ricky Beam <[EMAIL PROTECTED]> writes:
> syslogd isn't the blocker. The syslog functions in glibc being
> called by named are the problem. Stop named from blocking on syslog
> writes and the world will be happy again.
So I have the glibc maintainer (and others) saying that syslog
messages shou
Ricky Beam <[EMAIL PROTECTED]> writes:
> I would suggest disabling name resolution for syslog, but that's an
> ugly option. There's no way to stop a glibc system from doing a DNS
> query for a reverse lookup. HOWEVER, you can set the DNS timeout to
> 1 second and set the resolver options to pre
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> If anything has to be changed it's (as suggested) the configuration
> or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted reliable syslogging, it would be listening o
Jesse Pollard <[EMAIL PROTECTED]> writes:
> Don't configure syslogd to do reverse lookups.
Our syslogd has no option to disable the reverse lookups.
> You can NEVER guarantee that the reverse lookup will succeed, and
> can be delayed several minutes for a single reply.
Not true. The named on
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example, nobody can log in.
This happens because once the /dev/log buffer fills, the syslog()
glibc function blocks.
This is a problem
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Sure. I just don't see many end-users single-stepping through
> interrupt handlers etc.
>
> But yes, there probably are a few.
I think you would be surprised, and I speak as someone who has found
and fixed race conditions in your kernel.
There are m
12 matches
Mail list logo