On Thu, 21 Aug 1997, Benjamin C R LaHaise wrote:
>
> I've been thinking about the meta-data problem a bit on my own, and come
> to the conclusion: why not use the page-cache for directories too?
Directories I don't even consider "meta-data" for most filesystems: on
most filesystems directories are just another kind of file, and the page
cache lends itself well to it.
The real problem is the indirect block pointers.
Sorry for the late addition to this thread. (I've been away in Munich
for the IETF meeting, and I'm only now slowly responding to all of my
back-email messages.
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).
The reason why we need to handle 64-bit offsets in the page cache is to
support filesystems greater than 4GB, which do exist today.
- Ted
P.S. The other thing we need to fix about the VM system is that today,
if three processes have a shared map, and it is dirtied by the three
processes, the pages in that VM mapping apparently get written out three
times, because the dirty bit is per process instead of per-page. This
can be severely non-optimal for certain performance critical
applications that have this access/modification pattern.