Subject: Re: system hang
To: None <port-i386@netbsd.org>
From: Germano Cesari <germano.cesari@tesoro.it>
List: port-i386
Date: 10/31/2002 10:18:07
I modified /etc/fstab so to have mfs mounted at boot, everything works
fine (maybe a little faster?) but here something strange happens:

when I start vmware (even with a machine with only 32 megs, the one that
worked fine without mfs), it just goes through (trough? :-)) the POST
and than simply HALT the whole system (I mean the NetBSD system), in
just 5 secs, without all the thrashing it used to do before mfs.

no hdd activity, no thrashing, nothing, just a plain _dead_ OS, and in a
matter of seconds. I kept this mummy frozen for the whole night, but I
dont think it was making improvements of any sort, I just dont think it
was doing anything at all... isnt that puzzling?

is there a way to monitor whats goin on? (is the system really frozen?
and if so, why? when I reboot I dont have any core file). Remote
connections of any sort are useless, the system is just down (ping works
anyway)... any clue? is there a way to probe for some cpu life-signs in
that state?

Germano

On Tue, 2002-10-29 at 17:41, Greywolf wrote:
> On 29 Oct 2002, Germano Cesari wrote:
> 
> # anyway, pstat -s tells me wd0b is at 7%, so whats the need of mounting
> # mfs on /tmp? do this make things faster?
> 
> In a word, yes.  Any program which needs temporary files with which to
> work (cc, sort, others...) will see an improvement, especially on slower
> machines (even on my workstation which is no slug, real time for a copy
> from disk to mfs is about half the time for a copy from disk to disk
> (and yes, I picked a filesystem on which I could cache-invalidate by
> umounting) of a 3.5MB file.  Time for mfs -> mfs copy appears to be
> about half that.  The difference on disk -> disk will depend on your
> disks.  But I digress.
> 
> Another advantage of mfs is that it goes *poof* on a reboot or unmount,
> so if the system crashes and your compilers or other things (like X)
> have left their garbage there, unable to recover, when the system comes
> back, it's already gone (never mind that /tmp is usually set to get
> cleaned on a reboot anyway...).
> 
> 				--*greywolf;
> --
>