Messages in this thread | | | Date | Wed, 30 Aug 2000 12:49:24 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: hfs support for blocksize != 512 |
| |
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/
| |