kim@amdahl.uts.amdahl.com (Kim DeVaughn) (05/05/88)
[ "A car is just a big purse on wheels." --Johanna Reynolds ] Attached are a couple small files that are making the BBS rounds, on how you can utilize the FFS on your *floppy* drives under 1.3. I did check with "Mr. FFS" at CBM (Steve Beats) before posting this, who replied: > No problem, you can make this as public as you like. I sort of admitted it > was possible at the developers conference this week end anyway. > > Steve Sooooo ... anyone out there with Gamma 7 (etc.) want to comment on just how *Fassssssst* our floppys can be ...? /kim # This is a shell archive. Remove anything before this line, then # unpack it by saving it in a file and typing "sh file". (Files # unpacked will be owned by you and have default permissions.) # # This archive contains: # README Mountlist echo x - README cat > "README" << '//E*O*F README//' This mount list will let you use the Fast File System (FFS) on a Floppy drive. The only important part of this mountlist is the one labeled "DF3:". As it is right now the Floppy which will be formated with FFS will be labeled as DF3: even though it will really be DF0:. If you notice in this mountlist label DF3: has a UNIT = 0 this points to df0: but if you wanted to use the external drive (DF1:) you would have to change this to UNIT = 1. Which ever drive you decide to use this will be the only drive that the disk formated with FFS will be able to be used in. If you insert it in the other drive you will get that NO DOS message. You can either replace your present MountList in the DEVS directory with this MountList or you can just Edit yours and ADD the part labeled DF3:. If you decide to edit yours don't forget the # sign at the bottom or it will not work correctly. Now after you have this MounList in your WorkBench 1.3 Devs directory you will still have to mount it so that the Amiga can see it. The easiest way is to add a comand to you Startup-Sequence, something like: Mount DF3: Of course do this before the Endcli part of your Startup-Sequence (I know everybody knows this but I had to say it just in case). Then all you have to do is reboot with your Woorkbench 1.3 disk (The one with the new mountlist) and open your CLI and Format a disk using the FFS system. For example if you were to leave it the way it is DF0: would be the FFS drive so you would type: FORMAT DRIVE DF3: NAME MyDisk FFS <RETURN> At this the Amiga will say to put in the disk to formated into DF3: which in reallity is DF0: and to hit return. When you do this and the Amiga formats the Disk you will get 2 Icons for the same disk 1 will say NODOS and the other will have the name of your disk, which in this example is MyDisk . You will ignore the NODOS Icon and just use other Icon. If you decide to change the UNIT to 1 then everything is the same except when the Amiga tells you to insert the disk to be formated in DF3: you insert it in DF1:. (Simple enough) This about covers everything I can think of except to say that remeber to do this only on a Backup of your Workbench 1.3 disk and that I am just passing along information and you are doing this at your own risk. And I take no responsibilities for any damage to software or hardware caused by you trying this procedure. If you are thinking after reading this diclaim er "Wow Sarge is letting this go to his head." You are probably right, but once I get started I get inspired and besides EVERYONE ELSE DOES IT so there. Tony PLINK ID SARGE* //E*O*F README// echo x - Mountlist cat > "Mountlist" << '//E*O*F Mountlist//' /* MountList for V1.3 */ /* Mount Entry for the new Console Handler */ NEWCON: Handler = L:Newcon-Handler Priority = 5 StackSize = 1000 # /* This is an example of an alternative type of non-filing device mount, used to mount the non-buffered serial handler */ AUX: Handler = L:Aux-Handler Stacksize = 6000 Priority = 5 GlobVec = -1 # /* This is an example of an alternative type of non-filing device mount, used to mount the pipe handler */ PIPE: Handler = L:Pipe-Handler Stacksize = 6000 Priority = 5 GlobVec = -1 # /* This is an example of a non-filing system mount using a handler written in C. */ SPEAKER: Handler = L:Speak-Handler Stacksize = 6000 Priority = 5 GlobVec = -1 # /* This is an example of a mount list entry for using the recoverable ram disk. Depending on the amount of memory you wish to devote to it, you may want to change the HighCyl value. */ VD0: Device = ramdrive.device Unit = 0 Flags = 0 Surfaces = 2 BlocksPerTrack = 11 Reserved = 2 Interleave = 0 LowCyl = 0 ; HighCyl = 79 Buffers = 5 BufMemType = 5 # /* Mount a 5.25" disk drive to be mounted as DF2: */ DF2: Device = trackdisk.device Unit = 2 Flags = 1 Surfaces = 2 BlocksPerTrack = 11 Reserved = 2 PreAlloc = 11 Interleave = 0 LowCyl = 0 ; HighCyl = 39 Buffers = 20 BufMemType = 3 # /* An example mount entry using the fast file system with a partition of the hard disk using the 2090 disk controller. PREP has been used to create the first partition (up to cylinder 20). The second partition is MOUNTed, using the following entry: (The hard disk is not included; this is only an example.) */ FAST: Device = hddisk.device FileSystem = l:FastFileSystem Unit = 1 Flags = 0 Surfaces = 4 BlocksPerTrack = 17 Reserved = 2 Interleave = 0 LowCyl = 21 ; HighCyl = 800 Buffers = 30 GlobVec = -1 BufMemType = 1 # /* Let's say you have an A2000 with an internal drive, and an external drive, and you want to refer to the external drive as DF1: as well as DF2: Well, this MountList entry will do it for you. This technique can be extended to provide you with a drive A: and B: if you really want. */ DF3: Device = trackdisk.device FileSystem = l:fastfilesystem Unit = 0 Flags = 1 Surfaces = 2 BlocksPerTrack = 11 Reserved = 2 PreAlloc = 11 Interleave = 0 LowCyl = 0 ; HighCyl = 79 Buffers = 20 BufMemType = 3 globvec=-1 # //E*O*F Mountlist// echo Possible errors detected by \'wc\' [hopefully none]: temp=/tmp/shar$$ trap "rm -f $temp; exit" 0 1 2 3 15 cat > $temp <<\!!! 56 516 2658 README 113 448 2999 Mountlist 169 964 5657 total !!! wc README Mountlist | sed 's=[^ ]*/==' | diff -bw $temp - exit 0 -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/06/88)
In article <30793@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com
(Kim DeVaughn) writes about how to make the fast filesystem work on
floppies.
There's not a lot we can do about this, since it's making the rounds
on BBS's and such, so might I recommend the following disclaimer be put onto
all such boards, and be inserted into the shar file that was posted.
*** WARNING ***
The accompanying information should be considered an intellectual
curiosity, and should be used only for private, personal experimentation.
UNDER NO CIRCUMSTANCES SHOULD YOU DISTRIBUTE FLOPPIES USING THE FAST FILE
SYSTEM UNTIL SUCH TIME AS COMMODORE OFFICIALLY APPROVES OF SUCH AN ACT.
PUTTING THE FAST FILE SYSTEM ON YOUR FLOPPIES IS *UNSUPPORTED*, AND
COMMODORE RESERVES THE RIGHT TO BREAK ANYTHING THAT ISN'T OFFICIALLY
SUPPORTED.
I personally don't want to see two flavors of floppy format until
the DOS can recognize it automagically. As things stand now, you have to
pull a lot of magic to get it to work, and it's still fraught with
inconsistencies. Nein, danke.
My $0.02...
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\
\_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorjesup@pawl15.pawl.rpi.edu (Randell E. Jesup) (05/07/88)
In article <5888@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <30793@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com >(Kim DeVaughn) writes about how to make the fast filesystem work on >floppies. > > There's not a lot we can do about this, since it's making the rounds >on BBS's and such, so might I recommend the following disclaimer be put onto >all such boards, and be inserted into the shar file that was posted. Even worse: it's almost guaranteed to fail eventually, because as Steve Beats said at Devcon: FFS doesn't understand removable media, therefor it probably doesn't dump buffers when a disk is removed. This could cause disks to be destroyed if you EVER change disks (of course, it might not too. BUT DON'T TRUST IT NOT TO KILL DISKS IF YOU PLAY THESE TRICKS!) // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
grr@cbmvax.UUCP (George Robbins) (05/08/88)
In article <861@imagine.PAWL.RPI.EDU> jesup@pawl15.pawl.rpi.edu (Randell E. Jesup) writes: > In article <5888@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > >In article <30793@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com > >(Kim DeVaughn) writes about how to make the fast filesystem work on > >floppies. > > Even worse: it's almost guaranteed to fail eventually, because as > Steve Beats said at Devcon: FFS doesn't understand removable media, therefor > it probably doesn't dump buffers when a disk is removed. This could cause > disks to be destroyed if you EVER change disks (of course, it might not too. > BUT DON'T TRUST IT NOT TO KILL DISKS IF YOU PLAY THESE TRICKS!) I think Steve allows that the diskchange command would allow you to safely remove the disks, however since the normal user has become habituated to popping disks in and out like a electrified toaster, it quite likely you'ed get burned at least a few times before the new rules sink in. I don't know how much sense using the FFS on floppies makes, however if you want to try it, proceed with caution and pass the warnings along to your friends in addition to any glowing "100 times faster" reports... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
avery@puff.cs.wisc.edu (Aaron Avery) (05/08/88)
In article <861@imagine.PAWL.RPI.EDU> jesup@pawl15.pawl.rpi.edu (Randell E. Jesup) writes: > Even worse: it's almost guaranteed to fail eventually, because as >Steve Beats said at Devcon: FFS doesn't understand removable media, therefor >it probably doesn't dump buffers when a disk is removed. This could cause >disks to be destroyed if you EVER change disks (of course, it might not too. >BUT DON'T TRUST IT NOT TO KILL DISKS IF YOU PLAY THESE TRICKS!) I take it an explicit 'DiskChange' would not be sufficient to take care of this since FFS 'doesn't understand removable media. But, do you know if FFS understands the ACTION_FLUSH packet? If so, a simple program which sends this packet to the FFS could make changing disks 'safe(er)'. -- Aaron Avery (avery@puff.cs.wisc.edu) ({seismo,caip,allegra,harvard,rutgers,ihnp4}!uwvax!puff!avery)
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (05/08/88)
In article <861@imagine.PAWL.RPI.EDU>, jesup@pawl15.pawl.rpi.edu (Randell E. Jesup) writes: > In article <5888@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > > > There's not a lot we can do about this, since it's making the rounds > >on BBS's and such, so might I recommend the following disclaimer be put onto > >all such boards, and be inserted into the shar file that was posted. > > Even worse: it's almost guaranteed to fail eventually, because as > Steve Beats said at Devcon: FFS doesn't understand removable media, therefor > it probably doesn't dump buffers when a disk is removed. This could cause > disks to be destroyed if you EVER change disks (of course, it might not too. > BUT DON'T TRUST IT NOT TO KILL DISKS IF YOU PLAY THESE TRICKS!) Hold on now ... let's not start a panic, guys. If you recall, I mentioned that before posting this technique, I sent it off to Steve for his comments, as I had similar concerns. And I included his reply to me in my posting. He didn't seem to get excited over it, and did not mention any potential problems or future incompatibilities that might occur. In fact, he said that he had hinted that such was possible during DevCon. So, before we burn up alot of net.bandwidth over this, perhaps Steve (are you there ?) could give us the facts. If this *is* a dangerous practice, everyone should certainly know that up front. If it's not, then it would be nice to know that too. And if it's a "use at your own risk, but don't come crying to me later ... maybe it *might* break" deal, well then ... caveat emptor. It might also be useful for someone who has 1.3 Gamma's to actually *try* this out, and let us know the results (Randell?, Leo?) /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
avery@puff.cs.wisc.edu (Aaron Avery) (05/08/88)
In article <3748@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <861@imagine.PAWL.RPI.EDU> jesup@pawl15.pawl.rpi.edu (Randell E. Jesup) writes: >I think Steve allows that the diskchange command would allow you to safely >remove the disks, however since the normal user has become habituated to >popping disks in and out like a electrified toaster, it quite likely you'ed >get burned at least a few times before the new rules sink in. After my posting regarding the use of diskchange with the FFS attached to the floppy, I decided to try it out. Yes, FFS seems to react correctly to the DiskChange command. It seems to be only a partial reaction, but it looks like a safe one. When I did some timing tests comparing the SFS (Slow Filing System) and the FFS (Fast Filing System) on floppy, I got the following results: On a disk with about 100 files and directories, I did listed their contents and found that the SFS disk took 17.76 seconds while the FFS disk took 12:87 seconds. This may not look like such a marked improvement, but this was on a freshly created 1.2 SFS disk, which isn't the slowest beast in the world. The FFS disk was still impressive. I only noticed a minor increase in transfer rate, probably since the floppies aren't really pushing the SFS to its maximum. It still irks me when people refer to the Amiga's floppy drives as being 'the slowest floppy drives in the 16-bit world', just because it can take so long to get a directory. They still have one of the fastest net data transfer rates 'in the 16-bit world'. -- Aaron Avery (avery@puff.cs.wisc.edu) ({seismo,caip,allegra,harvard,rutgers,ihnp4}!uwvax!puff!avery)
doug-merritt@cup.portal.com (05/10/88)
Randall & Leo's comments about the danger of FFS on floppies are
well taken.
Given that some people will be interested anyway (hey, they ARE pretty
slow!), then what conclusion do we reach?
How about a little hotkey input handler that you bring up when you
want to pop a FFS diskette, that flushes buffers and tells you
when it's safe?
Yes, this may still be risky. However, this would be handy even
with SFS (slow file system) diskettes...I get nervous sometimes
about popping them out; I'd love to have something that I could use
to guarantee no disk access will happen when I want to grab one.
Especially if it had an emergency option to forcibly stop all disk
i/o (and shut off the red light)...I get nervous about rebooting
during brain damaged disk acesses.
You know, a program crashes, all goes nuts, but the little red light
is still on...If you reboot at this point (and since it may never go
off, you may have to), and a disk read or write is happening, mightn't
the reboot cause a problem? Or am I confused?
Even if I'm all wet about that, the input handler seems like a must for
those who *do* decide to use FFS with diskettes.
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!dougkarl@sugar.UUCP (Karl Lehenbauer) (05/16/88)
In article <5256@cup.portal.com>, doug-merritt@cup.portal.com writes: > How about a little hotkey input handler that you bring up when you > want to pop a FFS diskette, that flushes buffers and tells you > when it's safe? How about getting a DISKREMOVED message and, if there are hot buffers needing to be written out, putting up a requester saying "Put the disk back in the drive, now!" then flushing when the disk is put back in, as the slow file system seems to do. This whole thing is a hack unless supported by CA. Speaking of hotkeys, there is one little hotkey that I'd very much like to do a disk flush before proceeding: Control-Amiga-Amiga -- "Now here's something you're really going to like!" -- Rocket J. Squirrel ..!{bellcore!tness1,uunet!nuchat}!sugar!karl, Unix BBS (713) 438-5018
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/16/88)
In article <1056INFO@NDSUVM1> elg@killer.UUCP (Eric Green) writes: >in article <5256@cup.portal.com>, doug-merritt@cup.portal.com says: >> How about a little hotkey input handler that you bring up when you >> want to pop a FFS diskette, that flushes buffers and tells you >> when it's safe? >> >What I'm wondering about is -- since FFS is so unsafe on floppies, >how can we trust our hard drives to it? > >That is, if there can be buffered data that hasn't been written to the disk in >eons, then, how do I know when it's safe to turn off my hard drive based >system? > Slight misunderstanding there, due to less-than-optimal wording by Doug Merritt. FFS currently does not know how to generate a DISKCHANGE signal internally. This means that if you mount FFS on to a floppy drive, when you eject the disk, FFS will sit there and go, "Duhhh?" This isn't so bad, except that FFS will do the same thing when you insert a new floppy in the drive. Since FFS has no idea that you've changed volumes, FFS assumes that the volume was never changed, and will write all over it based on now invalid values. Note that there are no outstanding buffers waiting to be written to the now-removed volume. AmigaDOS does not hold on to buffers like UNIX. Hence, removed volumes will always be consistent, provided you wait for the little red light to go out and stay out. So, in order to safely change disks with FFS mounted on a floppy drive, you have to say "DiskChange" on that drive. Since hard disks are typically fixed media, the inability to internally generate DISKCHANGED isn't a major problem for FFS. The only real losers in this scenario are the people with Bernoulli-type drives. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
doug-merritt@cup.portal.com (05/17/88)
Eric Green's point about FFS on hard disk is interesting...are you
supposed to "unmount" the drive or something before powering down?
As for FFS on diskettes, my latest thought is that you could have
an input handler watch for disk eject, and pop up a requestor demanding
that the diskette be put back so that dirty blocks could be written
out first. If there are any, that is. Once everything's been written,
or if it already had been, the input handler could arrange to have
a "diskchange" done automatically.
Wouldn't this make FFS safe?
Doug
---
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!dougdoug-merritt@cup.portal.com (05/17/88)
Karl, having ctrl-Amy-Amy flush buffers is dangerous. People often
reboot when they see trouble coming, to limit the amount of damage
that might get caused.
If the buffers to be flushed have been damaged by, say, a pointer
with a run-away program (or is that the other way around?) then
it would be very damaging to write them out!
Doug
---
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!doug