Slashdot Mirror

← Back to Stories (view on slashdot.org)

Phase Change Memory vs. Storage As We Know It

Posted by timothy on from the change-is-constant-and-welcome-to-2010 dept.

storagedude writes "Access to data isn't keeping pace with advances in CPU and memory, creating an I/O bottleneck that threatens to make data storage irrelevant. The author sees phase change memory as a technology that could unseat storage networks. From the article: 'While years away, PCM has the potential to move data storage and storage networks from the center of data centers to the periphery. I/O would only have to be conducted at the start and end of the day, with data parked in memory while applications are running. In short, disk becomes the new tape."

3 of 130 comments (clear)

  1. The 70's called. They want their I/O methods back. by fahrbot-bot · · Score: 4, Informative
    From TFA:

    There is no method to provide hints about file usage; for example, you might want to have a hint that says the file will be read sequentially, or a hint that a file might be over written. There are lots of possible hints, but there is no standard way of providing file hints...

    Ya, we had that back in the stone-age and Multics would have been poster-child for this type of thinking, but it was a *bitch* and made portability problematic. I think VMS has some of this type of capability with their Files 11 support - any VMS people care to comment. Unix (and most current OS) sees everything as a stream of bytes, in most cases, and this is much simpler.

    An OS cannot be everything to all people all the time...

    --
    It must have been something you assimilated. . . .
  2. Numonyx will probably make it happen by AllynM · · Score: 4, Informative

    Numonyx announced some good advances in PCM a few months back:

    http://www.pcper.com/comments.php?nid=7930

    Allyn Malventano
    Storage Editor, PC Perspective

    --
    this sig was brought to you by the letter /.
  3. Re:The 70's called. They want their I/O methods ba by Guy+Harris · · Score: 4, Informative

    From TFA:

    There is no method to provide hints about file usage; for example, you might want to have a hint that says the file will be read sequentially, or a hint that a file might be over written. There are lots of possible hints, but there is no standard way of providing file hints...

    Ya, we had that back in the stone-age and Multics would have been poster-child for this type of thinking, but it was a *bitch* and made portability problematic.

    No, Multics would have been the poster child for "there's no I/O, there's just paging" - file system I/O was done in Multics by mapping the file into your address space and referring to it as if it were memory. ("Multi-segment files" were just directories with a bunch of real files in them, each no larger than the maximum size of a segment. I/O was done through read/write calls, but those were implemented by mapping the file, or the segments of a multi-segment file, into the address space and copying to/from the mapped segment.)

    I think VMS has some of this type of capability with their Files 11 support - any VMS people care to comment. Unix (and most current OS) sees everything as a stream of bytes, in most cases, and this is much simpler.

    "Seeing everything as a stream of bytes" is orthogonal to "a hint that the file will be read sequentially". See, for example, fadvise() in Linux, or some of the FILE_FLAG_ options in CreateFile() in Windows (Windows being another OS that shows a file as a seekable stream of bytes).