[OT] RAM disk (tmpfs) locking up

[Julian Foad <ju...@btopenworld.com>]

When running the tests on a RAM disk (tmpfs) the process accessing the RAM disk sometimes locks up and no "kill" signal can kill it.  This is not specific to Subversion; I assume it is a bug in the shmfs driver.  I particularly noticed that deltes like "rm -rf /tmp/ramdisk/svn-check/" often trigger a seg fault and/or lock-up.  I tried sending it, as root, all the signals numbered from 1 to 31, and still the "rm" process remains in the process list, in the state "D" or "Z".  The same for a "lt-svn" process which hung.

A while back I searched on Google and found one or two reports of this sort of problem but no useful answer.

Any ideas?

As a work-around, is there any more forceful way to kill a process than "for i in `seq 1 31`; do kill -n $i PID; done" ?  When that doesn't work I resort to re-booting.


> uname -a
Linux linux 2.4.21-99-default #1 Wed Sep 24 13:30:51 UTC 2003 i686 i686 i386 GNU/Linux
> mount
[...]
tmpfs on /dev/shm type tmpfs (rw)

This mount was provided by default in my SuSE Linux 9.0.

I was running the tests in "/tmp/ramdisk" which was a symlink to "/dev/shm" (or to "/dev/shm/ramdisk" after "mkdir /dev/shm/ramdisk").  If I instead "mkdir /tmp/ramdisk", everything works fine but of course slowly because it is on disk.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [OT] RAM disk (tmpfs) locking up

[Tobias Ringstrom <to...@ringstrom.mine.nu>]

Julian Foad wrote:

> When running the tests on a RAM disk (tmpfs) the process accessing the 
> RAM disk sometimes locks up and no "kill" signal can kill it.  This is 
> not specific to Subversion; I assume it is a bug in the shmfs driver.  I 
> particularly noticed that deltes like "rm -rf /tmp/ramdisk/svn-check/" 
> often trigger a seg fault and/or lock-up.  I tried sending it, as root, 
> all the signals numbered from 1 to 31, and still the "rm" process 
> remains in the process list, in the state "D" or "Z".  The same for a 
> "lt-svn" process which hung.
> 
> A while back I searched on Google and found one or two reports of this 
> sort of problem but no useful answer.
> 
> Any ideas?

I recommand that you either send a bug report to Suse, or run a vanilla 
kernel and report the bug (if it still exists) to the Linux kernel 
mailing list (lkml).

> As a work-around, is there any more forceful way to kill a process than 
> "for i in `seq 1 31`; do kill -n $i PID; done" ?  When that doesn't work 
> I resort to re-booting.

Nope.  But kill -9 is as powerful as it gets, so you don't really need 
to try the other ones.

/Tobias


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org