On Wed, 30 Aug 2000, Roman Zippel wrote:
> VFS isn't really wrong, the problem is that it moved from an almost
> single threaded API to a multithreaded API and that development isn't
> complete yet.
Sorry, it's a complete bullshit. VFS had been multi-threaded from the very
beginning. You are confusing SMP-threading (internal VFS contention on BKL
removed) and good old MT that has nothing to SMP. Damnit, you complain
yourself about _more_ locking done in VFS (why, BTW?)
Roman, these issues are _not_ new. I can reproduce these races on 1.3,
damnit. Please, stop pretending that they have something with recent VFS
changes or with SMP. It is simply not true. Provably not true.
> I don't really expect that fs programming becomes easier,
> but it should stay sane.
So _what_ _exactly_ had changed in the API that made it insane? And when?
> For example I want to protect certain state
> changes properly and not that insane "check all possible states at all
> possible times and before and after every change" what Al is currently
> doing in ext2.
Roman, could you please _read_ the ext2 code? What "all possible states"?
As for AFFS directory format - fine, please describe the data
manipulations required by unlink("foo"); done after the
link("foo","bar/baz");. Both operations are supported on AmigaOS, so
references to UNIX are utterly irrelevant. On the block level, please.
Only for directory blocks. Now, tell me what kind of protection (pageout
has nothing to directories, so all async problems are irrelevant) would
you provide. Or what protection should VFS/core kernel/exec/whatever
provide to filesystem. 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.
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 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 : Wed Aug 30 2000 - 12:50:57 EDT