On Wed, 30 Aug 2000, Roman Zippel wrote:
> 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.
Show me these removed locks. The only polite explanation I see is
that you have serious reading comprehension problems. Let me say it once
more, hopefully that will sink in:
Your repeated claims of VFS becoming more multi-threaded in ways
that are not transparent to fs drivers wrt locking are false.
If you disagree - show me the proof.
> 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
The problem with your solution is that it kills the box dead in a couple
of minutes. Otherwise it's just fine.
> 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
What? You've proposed locking on pageout. If _that_ isn't the fast path...
> 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.
> 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
Wrong. As the matter of fact, we could trivially get rid of _any_ use of
bread() and friends on ext2.
> thread, which can sleep for the caller. Another possibility is to make
_One_ thread? For the whole fs? So you would pass the dirty pages from
kswapd to that guy. Fine. It attempts to acquire the inode semaphore (in
your proposal, as far as I could parse it). It blocks. kswapd keeps
pumping dirty pages into the queue of that thread. Wonderful...
Notice that this mechanism (even if you will manage to fight deadlocks,
etc.) is
a) totally not needed for filesystems that do not have sparse
files.
b) doesn't help AFFS directory problems
c) doesn't help dealing with the data structures shared by several
files.
d) is unnecessary for usual filesystems with sparse files.
> the already existing asynchronus interface in buffer.c available to the
> fs. Anyway, if we want an asynchronous fs interface, we need an
> asynchronous bffer 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.
Talk is cheap. If you can show the patch that would simplify ext2,
I'm sure that Ted will be glad to see it. Same for maintainers of other
filesystems. The only requirement is that it should work. Excuse me, but
the longer I read your postings the more it looks like you have no idea of
the things you are talking about. I would be glad to be proven wrong on
that one too ;-/
PS: repeating patently false statement (see above - "(re)moved locks" one)
and failing to provide any shred of proof is really a bloody bad form...
-
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:26 EST