Hi,
> 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.
For example the usage of inode lock changed pretty much and was partly
replaced with the page lock? I can still remember times, where all of the
fs stuff happened under the BKL, for me that means only a _single_ thread
of execution could be busy in the whole fs layer. IMHO that's not really a
prime example of multi-threaded programming, if you have a different
definition please let me now.
> What? You've proposed locking on pageout. If _that_ isn't the fast path...
No, I suggested a lock (not necessarily the inode lock) during allocation
of indirect blocks (and defer truncation of them).
> > 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.
Excuse my stupidity, but could you please outline me how?
> _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...
Sorry, but did you read my mail? The purpose of that thread is to sleep
and to get waken up to continue the IO. Not very much changes, except that
this thread can safely sleep, whereas kswapd can't.
Excuse my ignorance, but who does currently stop kswapd to start lots of
IO?
> b) doesn't help AFFS directory problems
Why the hell do you come always with this, I _never_ mentioned it.
> 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 ;-/
I'm very sorry to waste your precious time, but your fscking arrogance
makes me sick. What's your problem? Shall I first worship you as our fs
god who saved us from all races?
Sorry, but from time to time I prefer _first_ to think about a problem and
I try to understand it. One way to do this is to post questions and/or
suggestions to a mailing list (at least I thought so). If you have an
other suggestion please enlighten me.
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:26 EST