On Thu, 31 Aug 2000, Roman Zippel wrote:
> Disclaimer: I know that the following doesn't match the current
> implementation, it's just how I would intuitively would do it:
>
> - get dentry foo
> - get dentry baz
How? OK, you've found block of baz. You know the name, all right. Now
you've got to do the full tracing all the way back to root. During that
tracing you've got to do interesting things - essentially that's what Neil
and Roman are trying to do with fh_to_dentry patches and it's _not_
simple. Moreover, it's even worse than the current code wrt amount of IO
_and_ seeks. OK, nevermind, let's say you've done that.
> - lock inode foo
> - mark dentry foo as deleted
> - getblk file header foo
> - mark file header foo as deleted
?
> - getblk file header baz
You'll have to do it way before - how else would you find out that it was
called baz, in the first place?
> - update file header baz from file header foo
If it would be that simple... Extent blocks refer to foo, unfortunately.
Yes, copying the thing would be easier. Too bad, data structure prohibits
that.
> > On that specific operation. When you are done with
> > that, I have a rename() for you, but I think that even simpler example
> > (unlink()) will be sufficient.
>
> Please post it, I know there are some interesting examples, but I don't
> have them at hand. Although I wanted to keep that flamewar for later, but
> if we're already in it...
Well, consider rename over the primary link and there you go... Keep in
mind that extent blocks contain the reference to header block, so unless
you want to update them all you've got to move the header into donor's
chain ;-/
> > Again, we are talking about the data structure and operations it has to
> > deal with _according to its designers_. I claim that due to a bad data
> > structure design (single-linked lists in hash chains, requirement to have
> > all entries belonging to some chain) unlink() (one of the operations it
> > was designed to deal with) becomes very complicated and requires rather
> > hairy exclusion rules. On Amiga. Linux has nothing with the problem.
>
> To be fair it shoud be mentioned, that links were added later to affs.
Well, but we've got to deal with the result, not with the
AFFS-without-links. I certainly agree that most of the blame for bad data
structure design falls on the folks who added that kludge for
pseudo-links, but that's purely historical question. Result is ugly.
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
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.
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
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.
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").
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:28 EST