Fast network file copy; "recvfile()" ?

2008-01-17 Thread Patrick J. LoPresti
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

2007-08-27 Thread Patrick J. LoPresti
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

2005-04-19 Thread Patrick J. LoPresti
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

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

2001-01-22 Thread Patrick J. LoPresti
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

2000-10-26 Thread Patrick J. LoPresti
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

2000-10-23 Thread Patrick J. LoPresti
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

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

2000-10-23 Thread Patrick J. LoPresti
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

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

2000-10-23 Thread Patrick J. LoPresti
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

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

2000-10-23 Thread Patrick J. LoPresti
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

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

2000-10-23 Thread Patrick J. LoPresti
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

2000-10-23 Thread Patrick J. LoPresti
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

Re: Availability of kdb

2000-09-08 Thread Patrick J. LoPresti
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