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.021 / U:89.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site