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