lkml.org 
[lkml]   [1997]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.747 / U:1.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site