Alexander Viro wrote:
> On Wed, 30 Aug 2000, Roman Zippel wrote:
> > > 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).
>
> Which means pageout when you are dealing with sparse files. You
> don't have them - fine, then you can take such lock right now.
>
[...]
> >
> > 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.
>
> No problem with _that_.
>
> How about we all calm down and do something more useful than this pissing
> match? One thing that became really obvious is that current documentation
> is either not enough or not read. Hell knows what to do about the latter,
> but the former can be helped. We have several pieces of it - Richard's one
> in the tree, Daniel's postings on fsdevel
Funny you should mention that - I was just reading this thread and
thinking "now, how the heck and I going to make some sense of the
locking rules in the new VFS?". I'm getting to the point where I have
to deal with some subtle issues in my own code and I thought I'd
approach this by writing down the locking rules. Then I realized that
since I don't have a clue where to start, I'd better do some deep
breathing, relax and think about it. Here's were I am now:
1) I want to think about what the absolute minimal level of locking
for FS ops could be. This is the same as asking what the maximum
parallelism could be. This is not necessarily going to resemble the
current arrangement very much, and it might give shivers to some fs
programmers that are used to being able to count on certain
traditional regions of mutual exclusion.
2) Then I have to go look at the current practice, and get it down in
some sort of notation that's easy to understand.
3) At this point I'd have the two endpoints of a migration path: where
we are (on the road away from BKL) and where we're going (towards the
tightest, most parallel fs you ever did see:-). This should be useful
in assessing how long that road is, and hence, just how far we are
from having the locking rules settle down.
4) Then post the draft, hopefully attracting some of the usual
flamage. In other words, trial by fire.
> and several parts written by
> various folks. This stuff needs to be merged (and corrected where needed).
> I volunteer to do that - I've spent quite a while dealing with the code,
> so I at least know what _is_ there. I would be really grateful if
> * folks who have writeups would post URLs to them (or texts
> themselves, if they are small enough). Preferably to fsdevel, but private
> email will also go.
Please cross-post to linux-doc@vger.kernel.org and
kernel-doc@nl.linux.org as well. On the theory that having more
copies of documentation is always better than less.
> * people would comment after the result will be posted. Especially
> about the missing / hard-to-understand pieces of text.
> * somebody helped to turn the result into decent English text.
There are a number of native English speakers hanging on the linux-doc
list, just waiting to be asked.
-- Daniel - 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:27 EST