lkml.org 
[lkml]   [1999]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: raw backing store
I may be talking out of my hat here, but I remember something similar in the news
from last year. Some university-of-queensland fellow had found some way (so the
story goes) to pack a terabyte or so of fast static ram into a single unit about
the size of a pcmcia card, and put an IDE interface on one end. It was supposed
to be about 20ns or so, IIRC. And it was supposed to be cheap. The papers said he
got hired by a memory manufacturer who wanted to (a) remain nameless and (b)
retail the unit.

Hadn't heard a thing since.

D


Alan Cox wrote:

> > 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
>
> You run off and sell it to the NSA. Actually with that spec of toy I'd
> expect the department of interesting toys would buy you out and sit on it
>
> > 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)?
>
> You need a file system to put files on any media.
>
> > 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
>
> And your memory leaks are saved, your saved structure isnt platform portable.
> The pointers in it go bad if they point to transient objects someone else
> has.
>
> > 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
>
> Thats fine. You still need journalling , you still need recovery from
> corruption. 20Gig is a lot of cosmic rays etc 8)
>
> All that changes is the disk layout becomes a little less important.
>
> Alan
>
> -
> 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/





-
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    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site