sterling@dasys1.UUCP (Sterling Brown) (08/28/88)
I was thinking a while back about the Fast File System not being put on the
floppies in AmigaDos 1.3. It is my understanding that the Fast file
system will not work on the floppies because it is not installed when
the Amiga boots, and Commodore is not putting the FFS in ROM because of
compatibility with the existing file system. Is this true?
If this IS true, then I have a suggestion:
Why not put the FFS in ROM, and if someone wants to access files in the old
format then they can install the Slow File System for the device on which
they will be accessing the files. This way people can install the old file
system on a drive and transferer everything over to the FFS once. This
will get rid of the problem of having a Slow File System boot partition on
the hard drive, and will make those of us using only floppies happy.
Comments? C-A?
\===========================\ /===========================/
\ Sterling L. Brown........ \ / "When I'm Programming /
\ \ / MSDOS, I'm thinking /
\ Amiga Programmer \=============/ of Amiga."-I said it. /
\ MSDOS Programmer /
\================\ `The Human Opperating System' /================/
A // Serious \ CIS: 71101,616 /Multifinder.status=
\\ // Amiga \ USENET: sterling@dasys1 / "don't make me laugh!";
\\/ Programmer \=========================/ OS2->bites=Amigas.Dust;melnik@topaz.rutgers.edu (Ofer Melnik) (08/29/88)
In article <6123@dasys1.UUCP> sterling@dasys1.UUCP (Sterling Brown) writes: | | I was thinking a while back about the Fast File System not being put on the | floppies in AmigaDos 1.3. It is my understanding that the Fast file | system will not work on the floppies because it is not installed when | the Amiga boots, and Commodore is not putting the FFS in ROM because of | compatibility with the existing file system. Is this true? As far as I know, the reason Commodore is not supporting FFS for floppies is that FFS currently does not support automatic detection of disk changes therefor, if you switch disks without telling it, you will probably have two mangled disks on your hands. Also, if I read correctly, FFS should be in ROM by 1.4. | |\===========================\ /===========================/ | \ Sterling L. Brown........ \ / "When I'm Programming / | \ \ / MSDOS, I'm thinking / | \ Amiga Programmer \=============/ of Amiga."-I said it. / | \ MSDOS Programmer / | \================\ `The Human Opperating System' /================/ | A // Serious \ CIS: 71101,616 /Multifinder.status= | \\ // Amiga \ USENET: sterling@dasys1 / "don't make me laugh!"; | \\/ Programmer \=========================/ OS2->bites=Amigas.Dust; -- Ofer Melnik Rutgers University melnik@topaz.rutgers.edu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/30/88)
: I was thinking a while back about the Fast File System not being put on the : floppies in AmigaDos 1.3. It is my understanding that the Fast file : system will not work on the floppies because it is not installed when : the Amiga boots, and Commodore is not putting the FFS in ROM because of : compatibility with the existing file system. Is this true? No, because except for autoboot the roms are not being changed AT ALL for the 1.3 release. By know, it is wayyyy to late to put anything else in the roms anyway (unless you want to wait another year for 1.3). But I haven't found this to be a problem.. really. You just reserve two or three cyls of your HD using the old filesystem so you can boot off of it (assuming the driver supports autoboot) and put the rest on the new filesystem. : If this IS true, then I have a suggestion: : : Why not put the FFS in ROM, and if someone wants to access files in the old : format then they can install the Slow File System for the device on which : they will be accessing the files. This way people can install the old file : system on a drive and transferer everything over to the FFS once. This : will get rid of the problem of having a Slow File System boot partition on : the hard drive, and will make those of us using only floppies happy. What I would like to see is an unmount command.... to unmount a device (i.e. DF0:) then remount it under the new filesystem. Even better, have the OS detect the disk format (easily done) and use the proper filesystem. -Matt
daveh@cbmvax.UUCP (Dave Haynie) (08/31/88)
in article <8808291950.AA12753@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: > > : I was thinking a while back about the Fast File System not being put on the > : floppies in AmigaDos 1.3. It is my understanding ... > > What I would like to see is an unmount command.... to unmount a > device (i.e. DF0:) then remount it under the new filesystem. Even better, > have the OS detect the disk format (easily done) and use the proper filesystem. You mean like 1.3's "Assign UNMOUNT DF0:" > -Matt You could probably set up a floppy with FFS, and it would be fast. The other problem you'd have is that it wouldn't know when a block went bad. The standard file system stores a 32 bit checksum in the block header of each block on your disk. Under FFS, there is no block header for data blocks. This has the nice feature of letting you store 512 bytes per block instead of 488, and it also lets multiple blocks be transferred directly to their destination, without any stripping. This makes lots of sense using hard disks or similar devices that do hardware error checking that's far superior to the file system's checksum. However, with a floppy, there is no underlying hardware error checking logic; the checksum is all you get. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
andy@cbmvax.UUCP (Andy Finkel) (08/31/88)
In article <4604@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <8808291950.AA12753@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: >> What I would like to see is an unmount command.... to unmount a >You mean like 1.3's "Assign UNMOUNT DF0:" Well, actually, no. That particular option of the assign command (which was renamed REMOVE to avoid just this kind of confusion) just lets you remove handlers and filesystems from the assign list (you can do the same thing with AssignDev) as a developer tool. (otherwise developing handlers and filesystems takes a lot of rebooting). The device being removed doesn't give up any of its resources. If I were using it to play dismount type of games, I'd inhibit the drive first, then remove it. A real dismount has to be implemented through a new packet; since one of the reasons that you want to dismount a handler or filesystem is so it gives up its resources. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/01/88)
>You mean like 1.3's "Assign UNMOUNT DF0:"
Really? Honest to goodness? Is the ACTION_DIE packet finally being
supported?
-Mattandy@cbmvax.UUCP (Andy Finkel) (09/02/88)
In article <8808311719.AA17625@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>You mean like 1.3's "Assign UNMOUNT DF0:" > > Really? Honest to goodness? Is the ACTION_DIE packet finally being >supported? Nope. Not for 1.3, anyway. I'd really like to for 1.4, though. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
jdow@gryphon.CTS.COM (J. Dow) (09/02/88)
In article <4604@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <8808291950.AA12753@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: >> >> : I was thinking a while back about the Fast File System not being put on the >> : floppies in AmigaDos 1.3. It is my understanding ... >> >> What I would like to see is an unmount command.... to unmount a >> device (i.e. DF0:) then remount it under the new filesystem. Even better, >> have the OS detect the disk format (easily done) and use the proper filesystem. > >You mean like 1.3's "Assign UNMOUNT DF0:" > >> -Matt > >You could probably set up a floppy with FFS, and it would be fast. The other >problem you'd have is that it wouldn't know when a block went bad. The standard >file system stores a 32 bit checksum in the block header of each block on your >disk. Under FFS, there is no block header for data blocks. This has the nice >feature of letting you store 512 bytes per block instead of 488, and it also >lets multiple blocks be transferred directly to their destination, without >any stripping. This makes lots of sense using hard disks or similar devices >that do hardware error checking that's far superior to the file system's >checksum. However, with a floppy, there is no underlying hardware error >checking logic; the checksum is all you get. >-- >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > "I can't relax, 'cause I'm a Boinger!" Er say what? I have page 49 of the DevConII notes for the hardware section open in front of me. Acto it there is the following sector organization: 2 bytes of 00 data - MFM = AAAA each 2 bytes of A1* - standard sync byte encoded A1 without clock pulse 1 byte format byte - amiga 1.0, 1.1, 1.2 == FF 1 byte track number 1 byte sector number 16 bytes of OS recovery info per note 2 (left out here) four bytes header checksum four bytes of data area checksum 512 bytes of data And this all repeats for each sector. So the floppies DO TOO have a checksum safety in them besides the SECOND checksum embedded within oldfs. Or do these C= notes lie to me? {O_O} -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
daveh@cbmvax.UUCP (Dave Haynie) (09/03/88)
in article <6177@gryphon.CTS.COM>, jdow@gryphon.CTS.COM (J. Dow) says: > Er say what? I have page 49 of the DevConII notes for the hardware section open > in front of me. Acto it there is the following sector organization: > [internal trackdisk format stuff...] > 16 bytes of OS recovery info per note 2 (left out here) > four bytes header checksum > four bytes of data area checksum > 512 bytes of data > And this all repeats for each sector. So the floppies DO TOO have a checksum > safety in them besides the SECOND checksum embedded within oldfs. Yup, there's a place for it. However, so far as I know, it isn't being used. I wondered about that stuff, since it's mentioned, long ago when I was writing the original DiskSalv. The general consensus was that there's nothing done with that stuff. I think that's still the case (I don't think 1.3 did any new work on trackdisk.device). Perhaps Steve Beats could tell us the truth. If this stuff really is being used, it may delay DiskSalv 1.2 a bit... > Or do these C= notes lie to me? I'm sure those locations exist. As far as I know, they're not generally used by a filesystem. They are also a pain to get to, since you're got to do raw read to see 'em. There are, of course, various kinds of lies. Mistakes, lies, LIES, benchmarks, spec sheets, and monthly columns in BYTE and InfoWorld. Take yer pick... > jdow@bix (where else?) -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (09/06/88)
In article <8808291950.AA12753@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > What I would like to see is an unmount command.... to unmount a >device (i.e. DF0:) then remount it under the new filesystem. Even better, >have the OS detect the disk format (easily done) and use the proper filesystem. > > -Matt I think, the last thing is nearly done in current AmigaDOS. The old filesystem and FastFilesystem use the first long word on sector zero to detect their format, i.e. DOS\0 is old file system, DOS\001 is FFS. If you run two filesystems on the disk they recognize only the right format but you get disk icons with the label DF1:DOS<A> (A invers) if you insert an FFS disk. Nevertheless, the main problem is that disk changing is not recognized by FFS and on the other way OldFS uses the TD_REMOVE call from trackdisk to detect disk changes, and those are overridden if another TD_REMOVE call is made. So both filesystemhandlers have to use TD_ADDCHANGEINT (right name ?). BTW, I have seen a gamma version of 1.3 that has an UMOUNT option with the ASSIGN command. That does not stop the handler for you cannot track down who actually is using the handler. But it removes the DosNode from the device list, so noone can find the handler. I think it would be better to terminate the handler and use a dummy handler that rejects all packets. Michael van Elst E-mail: UUCP: ...seismo!unido!fauern!faui44!mlelstv E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv <- when seismo ceases operation
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (09/06/88)
In article <4604@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > [ comments about FFS that has no DOS checksums on data blocks ] >....... However, with a floppy, there is no underlying hardware error >checking logic; the checksum is all you get. >-- I think you are wrong. I would agree that the data integrity is not checked very well. BUT trackdisk.device uses a parity check on each sector as well as on each sector header. You GET error messages from trackdisk if a block is wrong. And trackdisk does nothing with the DOS checksum. Trackdisk.device rejects complete tracks if only one sector is bad. (I verified this with a RAW_READ call and then decoding MFM data). Could anyone think to implement this in 1.4 ? BTW, some friends have improved the DiskSalv program to get all readable sectors from a bad track. Michael van Elst E-mail: UUCP: ...seismo!unido!fauern!faui44!mlelstv E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv <- when seismo ceases operation
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (09/06/88)
In article <8808311719.AA17625@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>You mean like 1.3's "Assign UNMOUNT DF0:" > > Really? Honest to goodness? Is the ACTION_DIE packet finally being >supported? > > -Matt Sorry. It is not. They only remove the DosNode from the device list. You can verify this by CD to the file system you want to unmount, then unmount it with ASSIGN and then watching that the filesystem is functional by simply reading a directory. (I had that before, hadn't I ? :-) Michael van Elst E-mail: UUCP: ...seismo!unido!fauern!faui44!mlelstv E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv <- when seismo ceases operation
charles@hpcvca.HP.COM (Charles Brown) (09/13/88)
>> Trackdisk.device rejects complete tracks if only one sector is bad. >> (I verified this with a RAW_READ call and then decoding MFM data). Could >> anyone think to implement this in 1.4 ? > Bad idea. For READING this is not a bad idea. You should be able to easily recover as much data from the disk as is good. Only the impacted sector(s) is defective. These are easily distinguished by bad CRC. It is only writing to a known bad track that is a bad idea. > Since disk writes aren't locked to the index hole under either > file system (thank god), any defect on the track will and should take out > the whole track. (After all, how do you know where the defect is going to > land.) This is a fallacy. It is only because the index hole is not locked to the start of the track that you don't know where the defect is going to land. The index hole was uncoupled from the track to speed access. But how much speed up did it accomplish? There are three cases: format, write and read. Format: Since formatting is done rarely (campared to reads and writes), a difference in speed has little effect upon total system speed. I choose to ignore it. Read: Reading does not depend upon the index hole anyway. It really only depends upon where the track was started when it was written. If you always start a track read at the beginning of a track (as written) you will on the average have a 1/2 rotation latency waiting for the disk to turn to the start of that track. So decoupling the index hole from the the start of track did not speed up reads AT ALL. Write: Writing a track can start at any time. This will save the time of (on the average) 1/2 rotation per track read. The minimum track read takes 1 rotation. Thus decoupling the index hole from start of track speed writes on the average by: difference=1/1.5=0.67 or 33% Now consider typical use. I don't have real figures so I will try to make them up. I would guess that I do reads at least 5 times as much as I do writes. I boot my A1000, use it a couple of hours, and turn it off. Booting takes a long time. Typical editing requires that I read the editor, read the file to be written, write the file one or more times. Typically the editor is a much bigger file that the file I am editing. Compiling requires reading several programs (make, cc, linker) the source(s), several libraries; and one or two files are written. So now how much speed did I gain? The following numbers represent time in terms of track rotations: write + read (weighed) index coupled: 1.5 + 5*1.5 = 9.0 index decoupled: 1 + 5*1.5 = 8.5 Now the advantage of decoupled index drops to 8.5/9.0=0.94 or 6% So we gave up track reliability for at best a 6% increase in overall floppy speed. That strikes me as a bad trade. > For floppies the point is moot. Use disks without flaws. They > aren't very difficult to find, and flawed disks will always end up being > more trouble than they're worth. How do you know a disk has no flaws? Formatting it does not tell you. The format program only puts data on parts of the track. Other parts of the track can be flawed and will still pass Format/Verify. There are two types of areas unchecked by Format. The gaps between sectors are not given data. The space between the end of the track and its own beginning has no data. When the index hole is coupled to the track start, these gaps are fixed in location and will never cause a problem. When the index hole is decoupled, they move about. Then you really have no way of knowing that the disk you are using is flawless until it fails. > If presented with a bad block the filesystem > assumes the worst, and ignores the track completely. Wonderful, nicht? > -Sullivan Segall Nicht! This flaw (decoupling index from start of track) could be fixed transparently in AmigaDos. It has no effect upon the reader; no changes would be required. Only writes and formats would be changed, to wait for index before doing their magic. The old reader and new readers (identical) would read data written by either writers; in fact they would have no way to know which type had written them. The new writers would not care whether a disk had been used by the old writer, it would always start the track at the same location anyway. So the reliability of AmigaDos could be improved by a at most 6% reduction in overall floppy speed. What do you say Commodore? Charles Brown charles%hpcvca@hplabs.hp.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/14/88)
In article <5660015@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >Read: > Reading does not depend upon the index hole anyway. It really > only depends upon where the track was started when it was > written. It doesn't even have to depend on that, and in fact, the trackdisk.device doesn't even care... > If you always start a track read at the beginning of a track > (as written) you will on the average have a 1/2 rotation > latency waiting for the disk to turn to the start of that > track. So decoupling the index hole from the the start of > track did not speed up reads AT ALL. But you don't always start a read at the beginning of a track. Trackdisk.device starts reading wherever the head is, and reads one full revolution plus enough extra to make sure it gets at least one intact copy of the sector it started reading on. So the total track read time should be constant: 1 rotation + 1 sector time + 1 index gap time. Since the gap varies due to variation in disk speed, etc., you have to allow some slop. I'd roughly estimate the result as being 1.1 rotations, not the 1.5 you came up with, so it does save a fair amount of time. Waiting for the index hole would also mean one more interrupt to process per sector. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
charles@hpcvca.HP.COM (Charles Brown) (09/15/88)
>> If you always start a track read at the beginning of a track >> (as written) you will on the average have a 1/2 rotation >> latency waiting for the disk to turn to the start of that >> track. So decoupling the index hole from the the start of >> track did not speed up reads AT ALL. > But you don't always start a read at the beginning of a track. > Trackdisk.device starts reading wherever the head is, and reads one > full revolution plus enough extra to make sure it gets at least one > intact copy of the sector it started reading on. So the total track > read time should be constant: > 1 rotation + 1 sector time + 1 index gap time. > > Since the gap varies due to variation in disk speed, etc., you have to > allow some slop. I'd roughly estimate the result as being 1.1 rotations, > not the 1.5 you came up with, so it does save a fair amount of time. > -=] Ford [=- Your argument only applys to reads. I am saying "don't change the way reads are done". So let me work thru the numbers with your correction: > The following numbers represent time in terms of track rotations: > write + read (weighed) > index coupled: 1.5 + 5*1.5 = 9.0 > index decoupled: 1 + 5*1.5 = 8.5 > Now the advantage of decoupled index drops to 8.5/9.0=0.94 or 6% becomes: The following numbers represent time in terms of track rotations: write + read (weighed) index coupled: 1.5 + 5*1.1 = 7.0 index decoupled: 1 + 5*1.1 = 6.5 Now the advantage of decoupled index drops to 6.5/7.0=0.93 or 7% So we gave up track reliability for at best a 7% increase in overall floppy speed. That strikes STILL me as a bad trade. Charles Brown charles%hpcvca@hplabs.hp.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/20/88)
In article <5660016@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >The following numbers represent time in terms of track rotations: > write + read (weighed) > index coupled: 1.5 + 5*1.1 = 7.0 > index decoupled: 1 + 5*1.1 = 6.5 >Now the advantage of decoupled index drops to 6.5/7.0=0.93 or 7% > >So we gave up track reliability for at best a 7% increase in overall >floppy speed. That strikes STILL me as a bad trade. But now you're using the "decoupled" figure of 1.1 in the "coupled" row. In the case of a random sector read, the average would be 1.5, not 1.1, giving a ratio of (6.5 : 9) == 0.72, a 28% savings. Also, your figures don't take into account that the 1.1 rotations of trackdisk result in up to eleven sector I/Os ("up to" because I won't assume that all the data on that track would be useful at that time), while the index-synced method would take 1.5 rotations to read ONE sector. Now, granted, the "conventional" method, under the right conditions, can then proceed to read several consecutive sectors, but this requires that the disk interleave be tuned to the specific application or it becomes 1.1 rotations per sector. The trackdisk strategy also relies on sequential access to boost performance; if sectors are being read sequentially it can be *eleven times* faster than the basic figures. On top of all that, the trackdisk method only needs fairly simple hardware, and has a much lower software overhead in terms of interrupt processing (only one interrupt per 11 sectors, instead of at least one for each sector) and in terms of real-time demands (the CPU doesn't have any real-time constraints with trackdisk, since it starts the DMA whenever it "feels like it", and the process completes automatically, with no immediate CPU responce required). Now, by "simulating" trackdisk with a conventional controller, (with track bufferring and always reading a whole track in (typically) 1.5 rotations), you can get back to the 28% difference in throughput, but index-syncing will still have extra CPU demands. A disadvantage of trackdisk, however, is the CPU processing required to "find" the sectors in the track of raw data, and the need to un-MFM the data. I don't know how long these operations take. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
charles@hpcvca.HP.COM (Charles Brown) (09/21/88)
>> The following numbers represent time in terms of track rotations: >> write + read (weighed) >> index coupled: 1.5 + 5*1.1 = 7.0 >> index decoupled: 1 + 5*1.1 = 6.5 >> Now the advantage of decoupled index drops to 6.5/7.0=0.93 or 7% >> >> So we gave up track reliability for at best a 7% increase in overall >> floppy speed. That strikes STILL me as a bad trade. > But now you're using the "decoupled" figure of 1.1 in the "coupled" row. I will paraphrase what I said: ------------------------------------------------------------------- * DO NOT CHANGE THE WAY YOU READ. ONLY CHANGE THE WAY YOU WRITE. * ------------------------------------------------------------------- Therefore READS TAKE THE SAME AMOUNT OF TIME whether the writes are decoupled from the index pulse or not. > In the case of a random sector read, the average would be 1.5, not 1.1, > giving a ratio of (6.5 : 9) == 0.72, a 28% savings. This is incorrect as noted above. > Also, your figures don't take into account that the 1.1 rotations of > trackdisk result in up to eleven sector I/Os ("up to" because I won't > assume that all the data on that track would be useful at that time), > while the index-synced method would take 1.5 rotations to read ONE sector. Incorrect. If you are trying to read or write (not both) 1.1 rotations result in eleven sectors read. The Amiga trackdisk device does not read half of a track, it always reads the whole track. Usefulness has nothing to do with it. I do not propose to change that. Your statement (with the term I/O) implys combined reads and writes. The Amiga does not read or write partial tracks. It also does not mix reads with writes during one track operation. I do not propose to change that. > Now, granted, the "conventional" method, under the right conditions, can > then proceed to read several consecutive sectors, but this requires that > the disk interleave be tuned to the specific application or it becomes > 1.1 rotations per sector. This is refering to single sector reads. I am not talking about that. > The trackdisk strategy also relies on sequential access to boost > performance; if sectors are being read sequentially it can be *eleven > times* faster than the basic figures. The "basic figures" you are talking about clearly must be single sector reads. I am not talking about that. > On top of all that, the trackdisk method only needs fairly simple > hardware, and has a much lower software overhead in terms of interrupt > processing (only one interrupt per 11 sectors, instead of at least one > for each sector) and in terms of real-time demands (the CPU doesn't have > any real-time constraints with trackdisk, since it starts the DMA whenever > it "feels like it", and the process completes automatically, with no > immediate CPU responce required). Again you are talking about single sector reads. I am not talking about that. > Now, by "simulating" trackdisk with a conventional controller, (with track > bufferring and always reading a whole track in (typically) 1.5 rotations), > you can get back to the 28% difference in throughput, but index-syncing > will still have extra CPU demands. > -=] Ford [=- See my first statement in this response. My numbers remain valid. We gave up track reliability for at best a 7% increase in overall floppy speed. It amazes me how easy it is to respond to a note without reading it. Charles Brown charles%hpcvca@hplabs.hp.com
peter@sugar.uu.net (Peter da Silva) (09/21/88)
In article <4774@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > Also, your figures don't take into account that the 1.1 rotations of > trackdisk result in up to eleven sector I/Os ("up to" because I won't > assume that all the data on that track would be useful at that time), > while the index-synced method would take 1.5 rotations to read ONE sector. Not true. He's not suggesting changing anything in the way you read a disk. He just wants to make the writes sync to the index hole so that damage to the disk won't result in trashing the whole sector. Thus, read times don't change at all and access is still 11 sectors at a time. This 11 sector business, by the way, would make more sense if you cached tracks for a while. What does it profit me to read in 11 sectors at a time when I'm just going to throw away 10 of them? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dml@loral.UUCP (Dave Lewis) (09/21/88)
In article <4774@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >In article <5660016@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >Also, your figures don't take into account that the 1.1 rotations of >trackdisk result in up to eleven sector I/Os ("up to" because I won't >assume that all the data on that track would be useful at that time), >while the index-synced method would take 1.5 rotations to read ONE sector. No, NO, NO!!!! He's said several times that the read operation would be identical; that only the writes would be aligned with the damn index mark like they should'a been all along! The read algorithm doesn't care where the track starts, it just finds the beginning and reads it. The real times, compared with the current (flaky) operations: (The way it is now = 1.0) Reads Writes Total (85% read, 15% write) ----- ------ --------------------------- 1.0 1.5 107.5 (7.5% longer) Writes currently take about 1 disk revolution. If ya have to wait for the index mark that adds 0.5 revolutions to the average write operation. Reads have to find the start-of-track NO MATTER HOW THE TRACK WAS WRITTEN, so aligning the tracks to the index will have NO EFFECT WHATSOEVER ON READ TIME! So we're putting up with wandering tracks (or musical sectors) for a measly 7.5% increase in floppy throughput. Even if you (unreasonably) assume 50% writes the difference is only 25%. This is a very small price to pay for increased reliability. -- Dave Lewis Loral Instrumentation San Diego (619) 282-3341 ihnp4 --\ bang --\ kontron -\ hp-sdd --\ calmasd ->-> crash ->--> loral!dml sdcrdcf -->--------> sdcsvax -/ (uucp)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/22/88)
: ------------------------------------------------------------------- : * DO NOT CHANGE THE WAY YOU READ. ONLY CHANGE THE WAY YOU WRITE. * : ------------------------------------------------------------------- :Therefore READS TAKE THE SAME AMOUNT OF TIME whether the writes are :decoupled from the index pulse or not. The problem is that there is no automatic index-start-dma thing in hardware... i.e., you get an interrupt on the index and the interrupt handler must then start the DMA. This means that while the track will be synced pretty close to the index, it won't be exact, and the system would have to map out, say, the sector before and after the bad one to be sure. Apart from that, it's a handy solution. -Matt
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/23/88)
In article <5660018@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >I will paraphrase what I said: > ------------------------------------------------------------------- > * DO NOT CHANGE THE WAY YOU READ. ONLY CHANGE THE WAY YOU WRITE. * > ------------------------------------------------------------------- Ok, I was confused about your suggestion. (I went back and read the first article and now your second article makes sense; thanks to Peter DaSilva for kicking me in the right direction). Most of the rest of my article makes sense only if we are comparing trackdisk to non-trackdisk (as I thought we were), but you were comparing trackdisk to hypothetical-modified-trackdisk and your figures did make sense all along to anyone who read your original posting. >> Also, your figures don't take into account that the 1.1 rotations of >> trackdisk result in up to eleven sector I/Os ("up to" because I won't >> assume that all the data on that track would be useful at that time), >> while the index-synced method would take 1.5 rotations to read ONE sector. > >Incorrect. If you are trying to read or write (not both) 1.1 >rotations result in eleven sectors read. The Amiga trackdisk device >does not read half of a track, it always reads the whole track. >Usefulness has nothing to do with it. Again, I was replying to a completely different interpretation of your message so I wasn't making much sense. But "usefulness" does have a lot to do with trackdisk input; those other ten sectors that are automatically read in when you ask for the first one can't be counted toward the throughput figures unless they will actually be requested and used by some program before they are flushed. This does not affect your proposal though. >We gave up track reliability for at best a 7% increase in overall >floppy speed. I think this statement is what led me off onto the wrong track... you make it sound as if we *used* to have this capability and lost it by going to track-at-a-time reads. But I realize you are suggesting an improvement to trackdisk, which can gain us this capability at only a slight performance penalty. I also agree with the way you came up with the 7% estimate. >It amazes me how easy it is to respond to a note without reading it. Actually, the problem was that I didn't read the first one, therefore the second one made no sense. Sorry. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.cbm.commodore.com
eachus@mitre-bedford.ARPA (Robert Eachus) (09/23/88)
Suddenly a light bulb appears over my head, switched on and shining brightly. Charles has had a brilliant idea, and like most great ideas it only seems simple IF you understand it. > ------------------------------------------------------------------- > * DO NOT CHANGE THE WAY YOU READ. ONLY CHANGE THE WAY YOU WRITE. * > ------------------------------------------------------------------- >Therefore READS TAKE THE SAME AMOUNT OF TIME whether the writes are >decoupled from the index pulse or not. This is the key insight. Writes can be coupled to the index pulse, and disks written by a "smarter" trackdisk.device can be read (and written to) by an old trackdisk.device with NO compaibility problems. >We gave up track reliability for at best a 7% increase in overall >floppy speed. Not quite, Charles, adding track reliablity won't cost even that much. Right now, trackdisk.device must rewrite an entire track even if only one sector is changed, and more important must read a track completely to write one sector. If a "smart" trackdisk.device knows where sectors are located, it can do single sector writes in an average of 0.7 rotations, instead of 2.2. For compatibility reasons it should not do this on non-FFS floppies, but if a floppy is FFS then there is no reason to allow for the "old style" writes. This means that ALL accesses would be as fast or faster except formatting and full track writes. >It amazes me how easy it is to respond to a note without reading it. Most of us (including Ford) try hard to UNDERSTAND what the author had in mind before responding. In this case, I think that the net traffic should be taken as evidence that some ideas are very hard to explain. In fact, since many people probaably don't understand yet, let me take another try. The key insight from Charles is that the model of the medium need not be the same when reading as when writing. When reading it is sometimes useful to ignore some of the rules which must be obeyed when writing. In this case the hang-up that most of us have is that if tracks begin at the beginning they must be read from the beginning. Okay who is going to be the first on his block to hack up trackdisk.device and try this for real? And please, Commodore, require that FFS sectors be keyed off of the index so that the "incompatible" fast single sector writes can be supported, even if the implementation of such writes has to wait for 1.5. Note that this feature really will have a significant impact on performance, since it will often be used to update directory entries. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
neil@amiga.UUCP (Neil Katin) (10/01/88)
<I tuned in late to this discussion; please don't flame me too bad>
<if I missed something that was said before>
As I understand the proposal, we want to change the way the trackdisk
writes to the disk: to sync writes with the index mark. This is
supposed to help recover the disk if there is a write error. Reading
the disk would be unchanged.
What escapes me is why this would help... The trackdisk uses
a level 6 interrupt to synchronize with the index mark. Because
it is an interrupt (and therefore s/w gets involved) anything that
stops or slows down interrupts will "shift" the start of the track.
This can include programs that call Disable() or things that starve
the processor of cycles (like a hard-disk doing DMA, or 4 bit planes of
high res, or the co-processor getting all the cycles, or the blitter
with the nasty bit set, etc).
Therefore your recovery s/w needs to be able to deal with tracks that don't
start at the index mark.
I have a different proposal. First of all, what's a bad, but recoverable,
disk (in the current format, at least)? It's one that has some good
sectors, and some bad ones. It also probably has some sectors that
that were left from the last time the disk was written. Currently
there is no way to tell if the sectors are from the "new" track,
or the "old" track. One way to cure this is to add a two bit "generation"
number to each sector. That way you can uniquely identify which
sector is new (or old), and you don't need to wait for the extra half
rotation for index to roll around.
Neil Katin
new mail address: {half the world}!sun!katinrokicki%polya.stanford.edu@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 7887; Sat, 01 Oct 88 01:04:53 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 01:04:51 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ad17521; 30 Sep 88 20:58 EDT Received: by Louie.UDEL.EDU id ae17361; 30 Sep 88 20:48 EDT Received: from USENET by Louie.UDEL.EDU id aa17067; 30 Sep 88 20:22 EDT From: "Tomas G. Rokicki" <rokicki@polya.stanford.edu> Subject: Re: Request to Commodore (Bad Blocks) Message-ID: <4204@polya.Stanford.EDU> Date: 30 Sep 88 21:51:01 GMT Organization: Stanford University To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Out of over 6000 Sony double-sided bulk floppies I have used, I have had about 12 go bad. -tom
neil%amiga.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 2439; Sat,
01 Oct 88 18:41:16 EDT
Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01
Oct 88 18:40:47 EDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ae17521; 30 Sep 88 20:58 EDT
Received: by Louie.UDEL.EDU id af17361; 30 Sep 88 20:48 EDT
Received: from USENET by Louie.UDEL.EDU id aa17103; 30 Sep 88 20:24 EDT
From: Neil Katin <neil@amiga.uucp>
Subject: Re: Request to Commodore (Bad Blocks)
Keywords: trackdisk floppy format
Message-ID: <2979@amiga.UUCP>
Date: 30 Sep 88 21:35:40 GMT
Organization: Commodore-Amiga Inc, Los Gatos CA
To: amiga-relay@UDEL.EDU
Sender: amiga-relay-request@UDEL.EDU
<I tuned in late to this discussion; please don't flame me too bad>
<if I missed something that was said before>
As I understand the proposal, we want to change the way the trackdisk
writes to the disk: to sync writes with the index mark. This is
supposed to help recover the disk if there is a write error. Reading
the disk would be unchanged.
What escapes me is why this would help... The trackdisk uses
a level 6 interrupt to synchronize with the index mark. Because
it is an interrupt (and therefore s/w gets involved) anything that
stops or slows down interrupts will "shift" the start of the track.
This can include programs that call Disable() or things that starve
the processor of cycles (like a hard-disk doing DMA, or 4 bit planes of
high res, or the co-processor getting all the cycles, or the blitter
with the nasty bit set, etc).
Therefore your recovery s/w needs to be able to deal with tracks that don't
start at the index mark.
I have a different proposal. First of all, what's a bad, but recoverable,
disk (in the current format, at least)? It's one that has some good
sectors, and some bad ones. It also probably has some sectors that
that were left from the last time the disk was written. Currently
there is no way to tell if the sectors are from the "new" track,
or the "old" track. One way to cure this is to add a two bit "generation"
number to each sector. That way you can uniquely identify which
sector is new (or old), and you don't need to wait for the extra half
rotation for index to roll around.
Neil Katin
new mail address: {half the world}!sun!katinneil%amiga.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 7926; Sat,
01 Oct 88 01:08:08 EDT
Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01
Oct 88 01:07:25 EDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ae17521; 30 Sep 88 20:58 EDT
Received: by Louie.UDEL.EDU id af17361; 30 Sep 88 20:48 EDT
Received: from USENET by Louie.UDEL.EDU id aa17103; 30 Sep 88 20:24 EDT
From: Neil Katin <neil@amiga.uucp>
Subject: Re: Request to Commodore (Bad Blocks)
Keywords: trackdisk floppy format
Message-ID: <2979@amiga.UUCP>
Date: 30 Sep 88 21:35:40 GMT
Organization: Commodore-Amiga Inc, Los Gatos CA
To: amiga-relay@UDEL.EDU
Sender: amiga-relay-request@UDEL.EDU
<I tuned in late to this discussion; please don't flame me too bad>
<if I missed something that was said before>
As I understand the proposal, we want to change the way the trackdisk
writes to the disk: to sync writes with the index mark. This is
supposed to help recover the disk if there is a write error. Reading
the disk would be unchanged.
What escapes me is why this would help... The trackdisk uses
a level 6 interrupt to synchronize with the index mark. Because
it is an interrupt (and therefore s/w gets involved) anything that
stops or slows down interrupts will "shift" the start of the track.
This can include programs that call Disable() or things that starve
the processor of cycles (like a hard-disk doing DMA, or 4 bit planes of
high res, or the co-processor getting all the cycles, or the blitter
with the nasty bit set, etc).
Therefore your recovery s/w needs to be able to deal with tracks that don't
start at the index mark.
I have a different proposal. First of all, what's a bad, but recoverable,
disk (in the current format, at least)? It's one that has some good
sectors, and some bad ones. It also probably has some sectors that
that were left from the last time the disk was written. Currently
there is no way to tell if the sectors are from the "new" track,
or the "old" track. One way to cure this is to add a two bit "generation"
number to each sector. That way you can uniquely identify which
sector is new (or old), and you don't need to wait for the extra half
rotation for index to roll around.
Neil Katin
new mail address: {half the world}!sun!katin