Messages in this thread | | | Date | Fri, 22 Aug 1997 14:45:50 -0400 | From | "David S. Miller" <> | Subject | Re: How to freeze 2.0.31 pre7 :( |
| |
Date: Fri, 22 Aug 1997 13:05:19 -0400 From: Bill Hawes <whawes@star.net>
Unfortunately this looks like a loop device too-many-dirty-buffers deadlock. In spite of the numerous kludges in the buffer code to attempt to circumvent such deadlocks, there appear to be cases that aren't covered.
I would very much like to see a loop device that operated only synchronously, so that there were _never_ any dirty loop device buffers.
Since this old issue is being brought up, I want to mention a few things.
Back a few months ago I started a half assed project to redo the entire I/O subsystem, a lot of people joined in and things began to happen, but due to various things (some people becomming fathers, others becomming busy for other reasons) the plane never left the ground.
Part of our foundation of initial ideas included a global I/O labelling strategy. Linus wants to keep the name buffer_head, and I agree with most of the technical details he has mentioned. I just don't think we should keep the name if we're changing the behavior radically on one end.
Here is sort of what we wanted things to look like (pay attention to architecture, not details):
1) Anyone who needs to move data between memory and a block device is by definition an I/O client, they are responsible for:
a) Determining where the buffers are in ram b) where it is on disk c) acquire exclusivity (wrt. SMP and traditional UP mutual exclusion issues) d) call into I/O request layer e) check for errors, unlock stuff
2) I/O request layer solely performs the function of:
a) Accepting calls in from clients, using the generic block device I/O tags, call them buffer_head or whatever, point remains the same b) Queue it c) Schedule to device driver d) Call back when done or error
One of the major goals was to put all the locking of resources at the client level, they can see more of their picture than the I/O request manager can, it is in fact none of his buisness, the locking. I believed that this could partly help with the loop device overcommital and other problems.
Second most important reason we wanted to rework things was so that we could allow for two important features block I/O in Linux needs badly:
a) physio b) arbitrary ordering constraints for the I/O operations
Also we wanted to add a more complete way for filesystems to enable a "sync it now like BSD, I don't care about performance and I don't believe that non-sync I/O won't lose data for me should the system go belly up and crash" mode. b) is for things such as logging filesystems where strict I/O ordering is a must. Ted T'ytso had plans to add such capabilities to ext2, but true I/O ordering is necessary for a correct implementation.
A quick mention back to the swap or anonymous inode idea. Adding it would allow us to do "safe" swapping, this would also make a lot of people happy who are more concerned about stability than raw performance. And it can be done such that the "rest of us" don't get penalized performance wise, only those who want anon swap preallocation eat the cost.
Later, David "Sparc" Miller davem@caip.rutgers.edu
| |