Messages in this thread | | | Date | Wed, 30 Aug 2000 13:57:12 +0200 | From | Roman Zippel <> | Subject | Re: hfs support for blocksize != 512 |
| |
Hi,
> Yes? And it will become simpler if you will put each and every locking > scheme into the API?
No, I didn't say that. I want the API to be less restrictive and make the job for the fs a bit easier. IMO the current API is inconsistent and/or incomplete and I'm still trying to find out what exactly is missing. The VFS is becoming more and more multithreaded, locks are (re)moved, but nothing was added for the fs.
> We have ext2 with indirect blocks, inode bitmaps and block bitmaps, one > per cylinder group + counters in each cylinder group. Should VFS know > about the internal locking rules? Should it be aware of the fact that > inodes foo and bar belong to the same cylinder group and if we remove them > we will need to protect the bitmap for a while?
Ok, let's take ext2 as an example. Of course vfs should only be the abstraction layer, but it shouldn't enforce locking rules like you added them in ext2. I know the races exists already longer, so you don't have to argue about that, but earlier I suggested a simpler solution, the problem is that it requires holding an exclusive lock while it would sleep. It wouldn't even be in the fast path and would only affect write access to the indirect blocks of a single file, it doesn't affect reads and it doesn't affect access to other files - that really shouldn't be a problem even for a multi threaded environment. But currently this is not possible and all I'm trying now is to explore possibilities to make that possible, as it would make the life for ext2 and every other fs a lot easier.
> We have AFFS with totally fscked directory structures.
Sorry? Why is that? Because it's not UNIX friendly? It was designed for a completly different os and is very simple. The problems I know are mostly shared with every other fs, that has a more dynamic directory structure than ext2.
> It's insane - protection of purely internal data structures belongs to the > module that knows about them.
I absolutly don't argue against that!
Anyway, somehow you skipped a lot of my mail, so it seems I have to continue to discuss that with myself (hopefully without permanent damage). The major problem right now is that writepage() is supposed to be asynchronous especially for kswapd, but the fs might have to synchronized something _internal_. I think one problem here is that we still have a synchronous buffer API, what makes it very hard to implement a asynchronous interface. That's why I suggested an I/O thread, which can sleep for the caller. Another possibility is to make the already existing asynchronus interface in buffer.c available to the fs. Anyway, if we want an asynchronous fs interface, we need an asynchronous buffer interface, so e.g. writepage() in ext2 can lock the indirect block, starts the I/O and gets called back later, another writepage() call in the same area has to detect that lock (with a simple down_trylock()) and schedules the complete I/O for later. With some help from the buffer interface it should be possible pretty easily and ext2 would actually become much easier again. Something like this would also be great for a real AIO support in userspace with great latencies.
bye, Roman - 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/
| |