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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:25 EST