#2090 HARDDISK CONTROLLER
16 messages in this thread
I have a sneaking suspicion that there is a "ceiling" around 60k or so, because
of DOS. Currently, anyway. As for the new file system, We're all still waiting,
and we (SoftCircuits) are still tweaking our own. As is Perry, If I have his
insinuations right… <grin>. –Ben–
Ben,
I keep hearing about faster file systems from you, but wonder if it's the way
to go. it would seem to me that we need one file system, not 2 or 3. Without
standardization in this area, how will anyone write anything that uses it?
Regards, Larry.
That's the whole idea of handlers! Unless you're writing something like
DiskSalv, where you really need to diddle with the structure, a file handler's
particulars should be local to that handler, and not at all obvious to the
outside world. In fact, if you can tell the difference, someone's not doing
their job in building their handler.
I agree that for floppies you need a standard file system to transfer data
between machines, but why on hard disks? If your file system adds speed or
something, that's the only difference you'd notice. Now if you start adding
special packets or something, then you get into specific handler support, but
those kind of things are best left to the supplier of the filesystem, and
anyone who wants to hack with them, rather than a thing you'd like to support
in a normal product.
-Dave
Dave,
I think you answered your own question when you said "Unless you're writing
something like DiskSalv". Since the handler is what determines the contents of
the blocks on disk, a different layout will break programs designed to work
with another layout. Sector editors, file recovery programs, disk mappers, etc.
will all require a knowledge of the mechanics of storing the file. A good
example is Sectorama, which only knows about the current file system. It can
still be used, but only in a limited and not overly friendly way.
Regards, Larry.
Larry; Would you say that you support the idea of not releasing a product that
can triple (or better, in Perry's case) the HD throughput of an Amiga system,
on the basis that SectorRama and it's brethren would no longer function?
–Ben–
Of course not Ben, i do, however, fully support having only one such product,
and having it supplied with the machine. As with anything else, the one that
comes with the machine is the one that the majority will use, but with just
enough users of 'some other system' to throw significant confusion into it.
Regards, Larry
I don't see why. There are a bunch of copy commands running around; And no one
seems to be confused. They all copy, they all work, and they're all more or
less compatible. Some are higher performance, some are missing features, but
they're all acceptable. Same thing. –Ben–
Ben,
it isn't the same thing at all. A copy program interacts with the OS on a
level that virtually guarantees compatibility. This will not be the case with
programs that, by necessity, need to go to the device level and know about the
file/disk format.
Regards, Larry.
Only repair programs need to do that — not "normal" application programs. A
file system interacts with this OS on a level that is just as standardized as
the DOS level; DOS packett level. If you describe a proceedure for "cleaning
up" a disk using the AmigaDOS copy commands interactive mode delete selection,
then a unix-style replacement is not only incompatible, but sadly deficient in
comparison. If you should try and clean up a disk partition with a tool not
meant to handle it, then you suffer… If the tool, on the other hand, uses the
file system in the prescribed manner, then it should work. I suggest that all
of us should be writing our stuff at that level. Otherwise things don't work
when the OS gets revved. As we have seen. –Ben–
Ben,
Repair, diagnostic, and investigative programs are exactly what I am talikng
about. You are talking about something at a higher level. Though higher level
programs can be used, you must admit that there really is no substitute for a
low level program that allows the grey computer upstairs to make decisions.
Regards, Larry.
I admit it – but I don't see it as a sufficient reason to forego
a significant performance advantadge in my work… The few times
that things have gone sour on me, usually due to software in the
pre-release stage (read, my fault) things have been so badly bit
in the chops that only many hours with those utilities could fix
even a fraction of the problems. The average user not only is in
a position where they don't have such utilities, they are unable
to use them if they had them. Whereas, if I were to release some
software that gave you, say, 250k throughput over the current or
then-current speed you were getting, I bet you'd dig in and MAKE
the utility you wanted. Or the whoever it is who makes those fix
it type of programs. Not me, that's for sure. –Ben–
Larry — it's (ours, anyway) totally transparent to the software that uses it,
unles said software uses direct-to-sector techniques like some games (cp'd) and
some utilities. Any software that is regular application software, follows
reg'lar dos rule, won't know it's running from our FFS. Only you will know,
because it's faster. There is no effort required from anyone to support it,
_except_ those who write disk-doctor type utilities… because they _care_
about the disk's actual sector-to-sector structure. –Ben–
My point exactly Ben… let's see… was this Benhandler or Perryhandler
format?
Or CBMhandler format… That's probably something that will add value for those
who write such things; It's not a good reason to skip the change. In any case,
because of the way it's implemented, you _do_ have a choice. You can keep the
old file format/handler, and run at your usual speed with all your disk tools
intact; Or, you can go with the new format, give up your disk tools, and run at
3x your old speed – or better. That's going to be an easy choice for most
people, either way. –Ben–
Ben, I also have reservations about having multiple FFS for HD's on the Amy.
Expecially if there isn't a significant difference in performance between the
FFS's. As Larry said, it will add confusion on using disk fix type software.
Of course, if each FFS came with it's own disk fix utilities I would be
appeased somewhat. BTW, what kind of performance are you getting with your
FFS? Do you have some DiskPerf results you could share with us?
Glenn
Glen, I 100% agree. An FFS implementation has two things to offer us, as users.
First, higher performance, and second compatability. I think that you should
choose the system that works best for you, in both ways. As for diskperf
figures, no, not yet. Still tweaking, and that makes a lot of difference. The
Amiga is _very_ sensitive to little changes in format and so on; We'll release
figures at the same time that we release the Beta stuff. We're kind of looking
at Perry's new system and CBM for some goals — we're not sure just how good
"good" is, if you follow me. –Ben–