Quoth a misinformed Alexander Viro re AFFS,
> As for the silliness of the OFS... I apologize for repeating the
> story if you know it already, but anyway: OFS looks awfully similar to
> Alto filesystem. With one crucial difference: Alto kept the header/footer
> equivalents in the sector framing. No silly 400-odd byte sectors for them.
> That layout made a lot of sense - you could easily recover from many disk
> faults, yodda, yodda, _without_ sacrificing performance. The whole design
> relied on ability to put pieces of metadata in the sector framing. Take
> that away and you've lost _very_ large part of the benefits. So large that
> the whole design ought to be rethought - tradeoffs change big way.
>
> OFS took that away. Mechanically. It just stuffed the headers into
> the data part of sectors. I don't know the story behind that decision -
> being a jaded bastard I suspect that Commodore PHBs decided to save a
> bit on floppy controller price and did it well after the initial design
Comododo PHBs had nothing to do with it. And the Commododo floppy
disk format is quite literally unreadable with a PC style controller. It was
not an economic decision. If you are going to carp please do so from a
basis of real knowledge Alexander. (The REAL blame for the disk fiasco
goes to the people at Metacrap^H^H^H^HComCo.)
> was done and so close to release that redesign was impossible for
> schedule reasons, but it might be something else. We'll probably never
> know unless somebody who had been in the original design team will leak
> it. But whatever reasons were behind that decision, OFS was either blindly
> copied without a single thought about very serious design factor _or_
> had been crippled at some point before the release. If it's the latter - I
> commiserate with their fs folks. If it's the former... well, I think that
> it says quite a few things about their clue level.
Metacomco designed it based on their TripOS. OFS is very good for
repairing the filesystem in the event of a problem, although the so called
DiskDoctor they provided quickly earned the name DiskDestroyer.
Metacomco and BSTRINGS and BPOINTERS and all that nonsense
entered the picture when it was decided the originally planned OS was
would take too long to develop. So what Metacomco had was grafted
onto what the old Amiga Inc had done resulting in a hodgepodge
mess.
> AFFS took the headers out of the data sectors. But that killed the
> whole reason behind having them anywhere - if you can't tell data blocks
> from the rest, what's the point of marking free and metadata ones?
> Now, links were total lossage - I think that even if you have some
Kemo Sabe, links never existed UNTIL the Amiga FFS was developed,
redeveloped, and redeveloped again.
> doubts about that now, you will lose them when you will write down the
> operations needed for rename(). And I mean pure set of on-disk changes -
> forget about dentries, inodes and other in-core data.
>
> Why did they do it that way? Beats me. AmigaOS is a microkernel,
> so replacing fs driver should be very easy. It ought to be easier than in
> Linux. And they've pulled out the change from OFS to AFFS, so the
> filesystem conversion was not an issue. Dunno how about UNIX-friendliness,
> but their implementation of links definitely was not friendly to their own
> OS.
As it turns out many of the recovery tools people built worked remarkably
well on FFS when it was introduced with little modification. (Most of the
time tracing the actual data blocks was not necessary for rebuilding the
disk. Thus the datablock metadata loss was not crippling.) FFS appeared
in its first versions with AmigaDOS 1.3. (Er, if you want a copy of some of
the earliest versions sent to developers for testing I can arrange something
in that regard. I believe I still have most of that "stuff".) It underwent
several
rewrites as successive developers and demands were placed on it. One
major change is evidenced in the hash algorithm used for the original
OFS and FFS. It fails to treat international characters correctly when
removing case. The international version corrected this deficiency. The
old cruft is preserved for reading old disks. Later on DirCache was added
principly for floppy disks. About that time Randall added both so called
soft links and hard links. For what it is worth it took a long long time and
series of modifications before either of them worked adequately.
> And let's not go into the links to directories, implemented well
> after it became painfully obvious that they were an invitation for
> troubles (from looking into Amiga newsgroups it seems that miracle
> didn't happen - I've seen quite a few complaints about fs breakage
> answered with "don't use links to directories, they are broken").
They MAY be fixed in the OS3.5 BoingBag 2 (service pack 2 with a
cutsiepie name.) Heinz has committed yet another rewrite.
> Anyway, it's all history. We can't unroll the kludge, no matter
> what we do. We've got what we've got. And I'm not too interested in
> distribution of the blame between the people in team that seems to be
> dissolved years ago. I consider AFFS we have to deal with as a poor excuse
> of design and I think that it gives more than enough reasons for that.
> In alternative history it might be better. So might many other things.
Indeed, poor or not it exists and we live with it in the Amiga community.
(Um, I wonder if I could talk Hendrix into a copy of the source for SFS so
it could be ported to Linux.... These days I prefer it to FFS. {^_-})
If you want I can bend your ear on things Amiga for longer than your
patience stretches, I suspect. (I've been following the threads discussions
because there is a project I'd like to port from NT to Linux that just ain't
gonna make it until some nice threads are added and latencies drop
dramatically. RT_Linux may be overkill. But as it sits today Linux is
underkill when you need 1/4 frame and less timing latencies on Show
Control operations. <petasigh>)
{^_^} Joanne "The Wizardess of Amigas" Dow, [EMAIL PROTECTED],
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
