Re: A memory-based filesystem for the lazy [or impatient]

[Roland McGrath]

Oh, how about that.  We already have store_buffer_create.
Hmm.  We have the "copy" store type, and the "zero" store type.
I don't have a running Hurd here to try this, but try something like this:

settrans -cpa /dev/ramdisk /hurd/storeio -Tcopy:zero 12345

where 12345 is the number of bytes in the store.  I might have the syntax a
little wrong, but the idea is you are creating a "copy" store whose
child store is a "zero" store with name "12345" (the number of bytes).  

A "zero" store is what /dev/zero is (always reads zeros), the setting on
/dev/zero gives no name (i.e. size) and the default size is the maximum
possible.  The only meaning of the size of a "zero" is what st_size will
report and what offsets it will let you try to read or write from--there is
never any data associated with a "zero" store.  (The code for this is in
libstore/zero.c.)

A "copy" store is meaningful only with respect to a child store.  What a
"copy" store does is to read the child store's entire contents into memory
at startup time and then use that buffer as the contents of the store
thereafter.  (The code for this is in libstore/copy.c.)  Because of how the
interfaces are specified, reading the entire contents of a "zero" store in
fact means just vm_allocate'ing fresh memory.  So, a "copy" store based on
a "zero" store is just what you'd get from vm_allocate'ing some memory and
passing it into store_buffer_create.