Re: questions about buffer.c

[Rik van Riel]

On Tue, 4 Jan 2000, Nicholas Mc Guire wrote:

>  trying to understand what is going on in fs/buffer.c

> 1) a buffer is clean aslong as it is only read from
>    and only becomes dirty if it is written to ?

Yes. Clean means that the buffer contains the same
data as the corresponding block on disk

> 2) a clean buffer never is flushed, does that mean it
>    is simply dropped if a different process requests
>    physical memory and no more free-buffers are around ?

Indeed. Since the buffer is clean there's no need to
write it out (the data is already on disk).

> 3) a locked buffer is locked by the process writing to it , a buffer
>    that was locked is always dirty ?

It would seem so. On readin, the usual (ext2) path locks an
entire page and not just one buffer. The breada read path
in buffer.c doesn't seem to use buffer_locked either...

> 4) if a dirty buffer is flushed is it always freed aswell ?

No. For instance see this snippet from fs/buffer.c::sync_buffers()

                        atomic_inc(&bh->b_count);
                        spin_unlock(&lru_list_lock);
                        ll_rw_block(WRITE, 1, &bh);
                        atomic_dec(&bh->b_count);

Here the count on the buffer is upped before the write so
nobody can free the buffer while we look the other way.

> 5) what is the relation between clean/dirty and swaping ? can a clean buffer
>    be swapped out or is it simply dropped and then reloaded if accessed at
>    its VFS-address ?

The latter is correct. No need to wait for a dirty buffer to
be written out when we can simply drop it. Besides, we'd need
to read it in again later anyway...

> 6) I expected that a dirty buffer that is flushed would be put on the clean 
>    buffer list until the process that was using it terminated , I could not
>    find where that would happen in buffer.c ?

Some places in buffer.c are actively moving buffers from
list to list, see flush_dirty_buffers() for an example.

> 7) are shared buffers never flushed until the last process using them exits ?

Nope, shared buffers are flushed like any other buffer. It's just
the freeing that's delayed until it has no more users.

Btw, it doesn't need to wait for any processes to exit, the buffer
cache is pretty much independant from processes, the number of
users is the number of places in the kernel where it is linked
into some data structure...

>  if someone has a better source than tlk-0.8-3.ps pleas let me know.

fs/buffer.c?

cheers,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.