Re: Review of Thomas's >2GB ext2fs proposal

[Thomas Bushnell BSG]

"Neal H. Walfield" <neal@cs.uml.edu> writes:

> Your other comments basically made sense, however, in the context of
> this statement, I have become extrememly confused.  So, before I react
> to your other comments, I would like you to elaborate what you mean by
> this statement.  Specifically, what about my proposal does not happen
> in user space?  What I suggest (and what Ogi has basically
> implemented) are changes to libpager (in the form of adding
> pager_notify_eviction) and modifying ext2fs to only map active
> metadata.  Nothing about this involves changes to the kernel; nothing
> I propose involves using undocumented features; everything I suggest
> functions within the Mach 3 framework.

Yes, my mistake; I was confusing it with a previous misunderstanding I
had!  Geez, this is what happens when I don't sleep enough.

What I really mean is that I can see no good reason to break the basic
structure of the memory object model.  For example, there is no good
reason to assume that the filesystem runs its own pager: in fact this
is really a mistake.  

A much better design would have the disk driver pager be used, and not
the filesystem's at all.  The only reason we can't do that is because
we need to control to deal with the file data pagers, especially since
the same disk block might be file data one day, and metadata (an indir
block) the next.

So what a nice interface would be (starting over in the design of
Mach) would allow multiple pagers to own a single memory page in some
fancy ass way.  Failing that, we have to lump the two pagers into one
program to get the necessary control.

But I think it's a mistake to take such heavy advantage of that
control, and it seems somewhat brittle to me as well.  

The only argument in favor of this proposal that I can see is that if
the paging tables in the kernel are unpageable, and if they are really
big, then my version might suck.  But I don't think that's a big
factor, because they are pageable, and because I don't think they are
so big anyway.

There is a disadvantage of my proposal which is the number of extra
memory objects that have to be kept track of: because it's an array of
memory objects, not just one, it might use more resources that way.

But on the other hand, your version suffers (in my opinion very
severely) because you basically can't allow the kernel to cache data.
You have taken over the caching policy for the kernel.  Since the
assumption we operate under is that the kernel can do better caching
than any user process (because it has a global view of the resource
situation) we don't want user processes taking over caching of the
actual disk data.  But because you must purge the data from memory any
time you remove the mapping, you now must think up a caching strategy,
compare it with the real ones in the kernel, and make sure it
interacts well.

By contrast, mine also requires a caching strategy, but it is only a
caching strategy for memory mappings, which, unlike core, are not a
limited globally shared resource.

Thomas