Fast network file copy; "recvfile()" ?

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

Fast network file copy; recvfile() ?

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

oom-killer with 27G free swap and overcommit_memory=2

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

oom-killer with 27G free swap and overcommit_memory=2

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

Re: Fortuna

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

Re: Fortuna

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 having

Re: [NFS] Help: 2.2.18 NFS is corrupting our files

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

Re: [NFS] Help: 2.2.18 NFS is corrupting our files

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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 /etc/hosts on your logmachine

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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 our

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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 on

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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 prevent

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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 should

Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x

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 too

Re: Availability of kdb

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

Re: Availability of kdb

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 more