[request for documentation]
Greetings,
I'm trying to grok the buffer cache/block devices, so I'm looking for
documentation on how the buffer cache is supposed to be used from a
block device driver. (With a specific goal in mind, which I'll get to
later.) I'm working with 2.2.13.
I've found:
http://www.linuxdoc.org/LDP/sag/x1565.html (user-level)
http://www.jlab.org/~saw/linux/tlk-html/node112.html (kernel, but I want
more detail)
http://nscp.upenn.edu/aix4.3html/aixprggd/kernextc/blockio_cache_kernsvcs_over.htm
(AIX, but helpful anyway)
Linux Device Drivers (Rubini) -- good, but doesn't seem to address
this...
What I want to know is, if I get a request to write a block that (due to
device characteristics) requires erasing a sector (sector = n * block),
can I load the n-1 blocks into the cache such that they will be written
through the request function at a later time?
>From my initial study of the code, I'm thinking something roughly like:
INIT_REQUEST
if we have to erase the sector,
for each of the n-1 blocks,
getblk()
if !buffer_uptodate() (this is a new buffer without data?)
copy the data to the buffer
mark_buffer_uptodate() (data is now valid)
if !buffer_locked() (if not scheduled for a write, make sure it
will be later.)
mark_buffer_dirty()
do the write
end_request()
So, am I completely wet behind the ears? :) I expect all the blocks in
the sector to be in one of three states at the end of the request; 1)
the block the request was about will be clean and written on the device,
2) the related buffers that are locked are still locked and will be
written out shortly or 3) the related buffers that are not locked are on
the dirty buffer list and will be written out a some later date.
Somebody correct me if that's not the case please.
Is there some documentation that describes the semantics of
buffer_uptodate(), _dirty(), _locked(), _req(), and _protected()?
I fear there will be gotchas in this, such as the possibility of a sync
dirtying buffers; would that be a problem? It should only do that on
the first pass; the second pass wouldn't dirty any more. Also, are
there locking issues, possible deadlocks, and/or race conditions I
should be aware of? It appears that the driver's request function is
called with the io_request_lock held and that changes to CURRENT request
must be done with that lock held, based on loop.c. So the request
function only needs to be re-entrant if we release the io_request_lock
temporarily?
Any and all pointers/comments/suggestions/whacks-on-the-head will be
greatly appreciated.
TIA,
Eli
-- --------------------. "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." eli.carter@inet.com `---------------------------------- (random fortune)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:27 EST