Rsync --daemon v 2.5.5 v26 causing kernel panic

Edward King edk at cendatsys.com
Tue Jan 14 14:31:02 EST 2003


Just did a successful rsync -- problem was with reiser filesystem.

Moved all files off the raid, ran reiserfsck with --rebuild-tree 
(fix-fixable was not enough), ran rsync after rebuild finished -- no 
problems.

There were a number of files that the rebuild-tree found that weren't 
attached

Edward King wrote:

> After switching much hardware (and getting some helpful suggestions) I 
> moved the specific machine's files on the backup server to a hard 
> drive outside the raid (still on the backup server, /dev/hdi1) and 
> tried rsync -- problem solved.
>
> It seems there's a problem with the journaled filesystems (reiserfs) 
> and raid -- reading the files is ok (cp command worked fine), writing 
> them is not.  
>
> I'm going to turn on reiser debugging and internal checks and re-run 
> -- maybe I can send something to the reiser or kernel people of 
> interest (don't want to go back to ext2)
>
>
> jw schultz wrote:
>
>>On Fri, Jan 10, 2003 at 02:25:57PM -0600, Edward King wrote:
>>  
>>
>>>Has anyone seen this?  Looking for past experiences / ideas.  Will post 
>>>progress.
>>>
>>>I'm tracking down a problem that seems to be caused by rsync.  When 
>>>moving files from a remote server I get a kernel panic.
>>>
>>>We have a number of servers that back up to a main box -- the panic only 
>>>occurs when a specific client backs up.  It occurs on the box it is 
>>>backing up to -- not the client.
>>>
>>>The kernel is Linux 2.4.20 (just compiled -- no patches), files are 
>>>stored on a 4 disk raid (80GB Western Digital drives, software raid) 
>>>with Reiserfs.  This is being done over a vpn connection controlled by 
>>>another machine (gateway machine) running tinc so we're not using ssh or 
>>>any other shell on the rsync machine.
>>>
>>>I have:
>>>
>>>recompiled rsync at both locations
>>>recompiled the kernel from new source code (panic in 2.4.19, system 
>>>rebooted in 2.4.20)
>>>
>>>I will:
>>>
>>>try different hardware
>>>run a file system check at the main system (the one that crashes)
>>>exclude directories in the backup (rsync one directory at a time -- see 
>>>where it crashes)
>>>
>>>I did notice filenames on the client machine that contain control 
>>>characters -- but they seem to have backed up before.
>>>    
>>>
>>
>>Just to confirm:  You are doing backup-server initiated pull
>>something like "rsync server::module destdir" and the
>>machine you execute this on (the receiver) panics.
>>
>>Rsync will of course not be the culprit.  However, rsync is
>>very good at stressing a system and the kernel developers
>>have found it to be a common test case.
>>
>>Most likely it is a hardware fault.  Probably timing
>>sensitive.  I'd check the logs for oopses and and disk
>>errors.  Also try downgrading the mode with hdparm.
>>
>>If this isn't a obvious hardware fault you should report it
>>to the linux-kernel people.  Look on www.kernelnewbies.org 
>>for instructions.  This will be of interest to the
>>developers of md, reiserfs and the specific IDE driver.
>>
>>  
>>
>

-------------- next part --------------
HTML attachment scrubbed and removed


More information about the rsync mailing list