lkml.org 
[lkml]   [1999]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectraw backing store
Does anyone (outside of db vendors) implement backing store on a raw
partition? What about X-server windows backing store?

I'm wondering what you do if you have 170gb of cheap, 20ns sram-workalike
on a chip instead of instead of disks. How do we leverage the efficiency
of that in the kernel? Do we still need a filesystem, ie some number of
huge ramdisks that are persistent? Or do we just have a database of
persistent objects, where a filesystem is just a particular view of it
(for the use of legacy software)?

The point is that with that much non-volatile ram, you don't work in
ram and then save to backing store, process stack/heap memory and backing
store are the same physical bytes. Your disk and ram are indexed by the
same vm system. As soon as your code creates a data structure in memory,
it's already "saved". A "file" is just a range of bytes in ram, and a
directory is just an index of a set of ram objects with the
directory/filesystem/partition in common (if one gets rid of
files/directories except as an overlay on ram, one still needs partitions
to keep runaway software juggernauts from scribbling all over vast amounts
of persistent storage, etc).

Do we need to split the kernel into two cooperating processes, one for
the fully-persistent processes and the other for transient state like
network connections and device interrupts? Otherwise, untangling the
transient stuff from the "saved at the point of creation" stuff when
the machine is suspended gets hairy (refer all of the past checkpointing
discussions). Perhaps just an explicit kernel model of transient vs
persistent state would do, ie socket stuff, signals, all of that is
in a memory range reserved for the transient parts of processes, that
the kernel knows to invalidate and rebuild on a reset or after an apm
resume or similar.

This stuff isn't as far away as one might guess, so think about it a
little. The filesystem isn't going to need to be able to optimize for seek
time on rotating/tape-streamed storage, so forward-looking index designs
should be *easily* convertible to what's optimum for a ram instead of a
long-latency disk. A filesystem that works best on a ramdisk is going
to be ready for the technology when it hits the market.

Regards,

Clayton Weaver
<mailto:cgweav@eskimo.com>
(Seattle)

"Everybody's ignorant, just in different subjects." Will Rogers




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.066 / U:0.916 seconds]
©2003-2014 Jasper Spaans. Advertise on this site