Assorted notes / code pointers from reading / discussions with
Chris Mason.

* linux/fs/ext3
    + home of the ext3 file-system.


there are two separate caches, the dentry cache and the inode cache.
dentries point to inodes and increment a reference count on the inode
object.  But, they have independent lifetimes, hashes and lookup
routines.  For example, sys_unlink() the dentry may away, but if the
file is open the inode will stay around because it can't be deleted
yet.

Also, hardlinks may mean that two dentries point to the same inode
etc.


The inode is read when the FS provided lookup routine is called.  This
happens some time after the dentry is created, and the inode is then
attached to the dentry.  (see ext3_lookup).


> - and will that not cause eg. ext3_get_inode_loc (from
> ext3_read_inode) to submit a buffer-head read twice on the same
> block ? [ presumably not - but I'm missing the cache there ].

ext3_get_inode_loc calls __ext3_get_inode_loc, who calls sb_getblk,
which is yet another way to access the page cache (in this case, it is
the page cache of the underlying block device (/dev/sdX or whatever).
getblk returns a block sized chunk (which may be different from a page
sized chunk).  __ext3_get_inode_loc does a check for buffer_uptodate,
and if the buffer isn't up to date it reads the block from disk.

    * critical hermenutical key:
	+ /dev/sdX is backed by the page-cache too ...

    * cf. 'sb_getblk' -> buffer.c (__find_get_block_slow) ->
	+ bdev->bd_inode ...

    * double reads ? another way
	- fill the page with 2 alignments ?


* madvise / fadvise / readahead.c
    + all end up in the same place:

 		ret = force_page_cache_readahead(mapping, file,
				start_index,
				max_sane_readahead(nrpages));
