Re: proposed change for async vbuffer heads

Linus Torvalds (torvalds@transmeta.com)
Tue, 26 Aug 1997 17:49:14 -0700 (PDT)


On Wed, 27 Aug 1997, Benjamin C R LaHaise wrote:
> On Tue, 26 Aug 1997, Theodore Y. Ts'o wrote:
> ...
> > If we can allow the page cache to handle 64 bit offsets even on the
> > i386, then there's a very simple solution. We simply access all of the
> > meta-data information (the superblocks, inode table, indirect block
> > pointers, etc.) via the page cache with the entire block device as the
> > blocking store. (i.e., what happens if you open /dev/hda1 directly and
> > go through the page cache).

Note that there is a much simpler approach, which I personally prefer
because "long long" tends to be extremely slow due to gcc not being very
good at it (gcc has also tended to have bugs in the long long handling).

The preferred approach for me is to make the page cache still use a
"unsigned long" for the offset within the cache, but make it be a "sector
number" or even a "page number".

With 512-byte sectors, 32-bit sector numbers gives up 41 bits of virtual
addressing per inode in the page cache. It's about as much physical space
as ext2fs can handle now anyway.

(one issue is also the size of the "struct page", which I perfer to keep
down).

> This is by far the right way to go if it weren't for one can of worms:
> aliasing. If an indirect block were accessed via the device's inode (say
> it's a 1024 byte block) and is immediately followed by a block of some
> file's data, writing to the indirect block would cause the dirty 'page'
> to be flushed, overwriting any update made to the file.

No, the page cache is always virtually addressed, so the physical location
on disk is irrelevant (anybody who tries to use the page cache as a
physical page will get stomped upon by the kernel anyway).

Linus