Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!gatech!gtss!chas
From: chas@gtss.UUCP (Charles Cleveland)
Newsgroups: comp.sys.amiga
Subject: Re: path: & 1.3 (also RAD: recovering)
Keywords: VD0:,recover,0xC00000
Message-ID: <288@gtss.UUCP>
Date: 4 Dec 88 22:29:11 GMT
References: <284@gtss.UUCP> <385@solaria.csun.edu> <2056@nunki.usc.edu>
Reply-To: chas@gtss.UUCP (Charles Cleveland)
Organization: Georgia Tech School of Physics
Lines: 75

In article <2056@nunki.usc.edu> raddison@castor.usc.edu (Richard Addison) writes:
)In article <385@solari.csun.edu> ecphssrw@trantor.csun.edu writes:
)>This is why RAD: doesn't recover.  No recoverable RAM disk can survive
)>in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for
)>its existence.  Only true FAST RAM will work.
)
)Funny thing, I've not had any major problems recovering VD0: in 0xC00000
)ram on my 2000 (with standard 512K chip, 512K "sync" memory).  Am I
)doing something wrong? (-;  I've even rebooted to disks without the VD0:
)driver (like the standard workbench, with the standard screen size) to
)do something quick and then have rebooted by customized environment with
)VD0: and have the contents remain.  This works only because I didn't
)make heavy memory demands in between.
)
)So what is the real story?
)
)Richard Addison  (Charles Rocket plays me on Moonlighting)

Well I don't know the whole real story, which I too would like to hear.
It involves the fact that the OS doesn't always feel a need to re-verify the
existence of C00000 memory on a warm boot, depending on how trashed the system
is.

I also got FFS RAD: quasi-recovering.  I just got through writing about it,
but I notice on looking back that it only went to comp.sys.amiga.tech and not
here, and since it may be of general interest I quote it below.

Comp.sys.amiga article follows ->

Newsgroups: comp.sys.amiga.tech
Subject: Re: Partitioning RAD:
Summary: 
Expires: 
References: <3012@sugar.uu.net> <282@gtss.UUCP> <3702@druwy.ATT.COM>
Sender: 
Reply-To: chas@gtss.UUCP (Charles Cleveland)
Followup-To: 
Distribution: 
Organization: Georgia Tech School of Physics
Keywords: 

In article <3702@druwy.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes:
)In article <282@gtss.UUCP>, chas@gtss.UUCP (Charles Cleveland) writes:
)> When I set up RAD: under FFS (but not under SFS), I seemed to have to format
)> it before using it even though it was a single filesystem, contrary to your
)> remark above.
)
)My RAD: is setup under FFS as a single filesystem, and it does not need
)to be formatted.  After mounting, RAD: is automagically formatted on cold
)boot (my MountList specifies Mount = 1, or whatever the parameter is, that
)tells it to load the handler immediately when mounted rather than waiting
)until the first access).  Make sure your MountList includes both the FFS
)handler and the dos type (I forget the exact names of the parameters).

Mount = 1.  That's the ticket.  Now not only does my FFS RAD: not need to be
formatted, but it has regained the quasi-recoverability (it goes in C00000
memory in my machine), like vd0:'s, that I had hoped for.

Examination of my startup-sequence reminds me that I had RAD: recovering
before while a slow-file system, but conversion to FFS without Mount = 1
if RAD: lives in C00000 apparently prevents any recoverability at all.

I was surprised, after adding 'Mount = 1' to my mountlist and removing the
format from my startup-sequence, when I rebooted with that disk and none
of the expected copies to RAD: occurred.  When I looked, RAD:'s contents
were still intact from yesterday, when it had been mounted without
'Mount = 1' in my mountlist.  In fact, in the meantime, I had even rebooted
twice from other disks that don't even know about RAD:, but use vd0: instead.

Thanks.  That hit the spot.
-- 
-  It is better for civilization to be going down the drain than to be  -
-  coming up it.                                        -- Henry Allen  -
Charles Cleveland  Georgia Tech School of Physics  Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas                INTERNET:  chas@gtss.gatech.edu