From: Pierre C
Subject: Re: SSD + RAID
Date: ,
Msg-id: op.u8kwherdeorkce@localhost
(view: Whole thread, Raw)
In response to: Re: SSD + RAID  (Scott Marlowe)
Responses: Re: SSD + RAID  (Nikolas Everett)
Re: SSD + RAID  (Scott Carey)
List: pgsql-performance

Tree view

SSD + RAID  (Laszlo Nagy, )
 Re: SSD + RAID  (Karl Denninger, )
  Re: SSD + RAID  (Laszlo Nagy, )
   Re: SSD + RAID  (Axel Rau, )
    Re: SSD + RAID  (Richard Neill, )
     Re: SSD + RAID  (Greg Smith, )
      Re: SSD + RAID  (Merlin Moncure, )
  Re: SSD + RAID  (Marcos Ortiz Valmaseda, )
 Re: SSD + RAID  (Scott Marlowe, )
  Re: SSD + RAID  (Merlin Moncure, )
   Re: SSD + RAID  (Scott Carey, )
    Re: SSD + RAID  (Merlin Moncure, )
 Re: SSD + RAID  (Heikki Linnakangas, )
  Re: SSD + RAID  (Merlin Moncure, )
   Re: SSD + RAID  (Heikki Linnakangas, )
    Re: SSD + RAID  (Merlin Moncure, )
     Re: SSD + RAID  (Heikki Linnakangas, )
      Re: SSD + RAID  (Merlin Moncure, )
  Re: SSD + RAID  (Laszlo Nagy, )
   Re: SSD + RAID  (Robert Haas, )
    Re: SSD + RAID  (Laszlo Nagy, )
 Re: SSD + RAID  (Greg Smith, )
  Re: SSD + RAID  (Karl Denninger, )
   Re: SSD + RAID  (Greg Smith, )
    Re: SSD + RAID  (Karl Denninger, )
     Re: SSD + RAID  (Scott Carey, )
      Re: SSD + RAID  (Tom Lane, )
       Re: SSD + RAID  (Jeff Janes, )
      Re: SSD + RAID  (Greg Smith, )
       Re: SSD + RAID  (Karl Denninger, )
    Re: SSD + RAID  (Brad Nicholson, )
     Re: SSD + RAID  (Dave Crooke, )
     Re: SSD + RAID  (Greg Smith, )
      Re: SSD + RAID  (Merlin Moncure, )
      Re: SSD + RAID  (Merlin Moncure, )
       Re: SSD + RAID  (Brad Nicholson, )
        Re: SSD + RAID  (Scott Marlowe, )
       Re: SSD + RAID  (Peter Eisentraut, )
       Re: SSD + RAID  (Greg Smith, )
        Re: SSD + RAID  (Merlin Moncure, )
         Re: SSD + RAID  (Greg Smith, )
          Re: SSD + RAID  (, )
           Re: SSD + RAID  (Scott Carey, )
            Re: SSD + RAID  (Merlin Moncure, )
             Re: SSD + RAID  (Scott Marlowe, )
              Re: SSD + RAID  (Greg Smith, )
               Re: SSD + RAID  (Merlin Moncure, )
                Re: SSD + RAID  (Scott Marlowe, )
        Re: SSD + RAID  (Mark Mielke, )
        Re: SSD + RAID  (Scott Carey, )
         Re: SSD + RAID  (Greg Smith, )
        Re: SSD + RAID  (Bruce Momjian, )
         Re: SSD + RAID  (Ron Mayer, )
          Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (Bruce Momjian, )
             Re: SSD + RAID  (Ron Mayer, )
              Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Ron Mayer, )
  Re: SSD + RAID  (Merlin Moncure, )
  Re: SSD + RAID  (Matthew Wakeling, )
   Re: SSD + RAID  (Bruce Momjian, )
    Re: SSD + RAID  (Dan Langille, )
     Re: SSD + RAID  (Bruce Momjian, )
      Re: SSD + RAID  (Scott Carey, )
       Re: SSD + RAID  (Bruce Momjian, )
        Re: SSD + RAID  (Ron Mayer, )
         Re: SSD + RAID  (Greg Smith, )
          Re: SSD + RAID  (Arjen van der Meijden, )
           Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (Mark Mielke, )
             Re: SSD + RAID  (Greg Smith, )
              Re: SSD + RAID  (Scott Marlowe, )
               Re: SSD + RAID  (Scott Marlowe, )
                Re: SSD + RAID  ("Pierre C", )
                 Re: SSD + RAID  (Nikolas Everett, )
                 Re: SSD + RAID  (Scott Carey, )
          Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Ron Mayer, )
            Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (, )
             Re: SSD + RAID  (, )
              Re: SSD + RAID  (Aidan Van Dyk, )
               Re: SSD + RAID  (, )
                Re: SSD + RAID  (Mark Mielke, )
                Re: SSD + RAID  (Dave Crooke, )
          Re: SSD + RAID  (Bruce Momjian, )
           Re: SSD + RAID  (Greg Smith, )
            Re: SSD + RAID  (Bruce Momjian, )
             Re: SSD + RAID  (Ron Mayer, )
              Re: SSD + RAID  (Greg Smith, )
               Re: SSD + RAID  (Bruce Momjian, )
              Re: SSD + RAID  (Bruce Momjian, )
               Re: SSD + RAID  (Greg Smith, )
                Re: SSD + RAID  (Ron Mayer, )
               Re: SSD + RAID  ("Pierre C", )
         Re: SSD + RAID  (Bruce Momjian, )
 Re: SSD + RAID  ("Fernando Hevia", )
  Re: SSD + RAID  (Greg Smith, )
 Re: SSD + RAID  ("Kenny Gorman", )
  Re: SSD + RAID  (Kenny Gorman, )
 Re: SSD + RAID  (Lists, )
  Re: SSD + RAID  (Ivan Voras, )
   Re: SSD + RAID  (Laszlo Nagy, )
    Re: SSD + RAID  (Craig Ringer, )
     Re: SSD + RAID  (Laszlo Nagy, )
      Re: SSD + RAID  (Craig Ringer, )
       Re: SSD + RAID  (Laszlo Nagy, )
     Re: SSD + RAID  (Craig James, )
      Re: SSD + RAID  (Heikki Linnakangas, )
     Re: SSD + RAID  (Scott Carey, )
      Re: SSD + RAID  (Craig Ringer, )
       Re: SSD + RAID  (Anton Rommerskirchen, )
        Re: SSD + RAID  (Brad Nicholson, )
      Re: SSD + RAID  (Greg Smith, )
       Re: SSD + RAID  (Matthew Wakeling, )
       Re: SSD + RAID  (Scott Carey, )

> Note that's power draw per bit.  dram is usually much more densely
> packed (it can be with fewer transistors per cell) so the individual
> chips for each may have similar power draws while the dram will be 10
> times as densely packed as the sram.

Differences between SRAM and DRAM :

- price per byte (DRAM much cheaper)

- silicon area per byte (DRAM much smaller)

- random access latency
    SRAM = fast, uniform, and predictable, usually 0/1 cycles
    DRAM = "a few" up to "a lot" of cycles depending on chip type,
    which page/row/column you want to access, wether it's R or W,
    wether the page is already open, etc

In fact, DRAM is the new harddisk. SRAM is used mostly when low-latency is
needed (caches, etc).

- ease of use :
    SRAM very easy to use : address, data, read, write, clock.
    SDRAM needs a smart controller.
    SRAM easier to instantiate on a silicon chip

- power draw
    When used at high speeds, SRAM ist't power-saving at all, it's used for
speed.
    However when not used, the power draw is really negligible.

While it is true that you can recover *some* data out of a SRAM/DRAM chip
that hasn't been powered for a few seconds, you can't really trust that
data. It's only a forensics tool.

Most DRAM now (especially laptop DRAM) includes special power-saving modes
which only keep the data retention logic (refresh, etc) powered, but not
the rest of the chip (internal caches, IO buffers, etc). Laptops, PDAs,
etc all use this feature in suspend-to-RAM mode. In this mode, the power
draw is higher than SRAM, but still pretty minimal, so a laptop can stay
in suspend-to-RAM mode for days.

Anyway, the SRAM vs DRAM isn't really relevant for the debate of SSD data
integrity. You can backup both with a small battery of ultra-cap.

What is important too is that the entire SSD chipset must have been
designed with this in mind : it must detect power loss, and correctly
react to it, and especially not reset itself or do funny stuff to the
memory when the power comes back. Which means at least some parts of the
chipset must stay powered to keep their state.

Now I wonder about something. SSDs use wear-leveling which means the
information about which block was written where must be kept somewhere.
Which means this information must be updated. I wonder how crash-safe and
how atomic these updates are, in the face of a power loss.  This is just
like a filesystem. You've been talking only about data, but the block
layout information (metadata) is subject to the same concerns. If the
drive says it's written, not only the data must have been written, but
also the information needed to locate that data...

Therefore I think the yank-the-power-cord test should be done with random
writes happening on an aged and mostly-full SSD... and afterwards, I'd be
interested to know if not only the last txn really committed, but if some
random parts of other stuff weren't "wear-leveled" into oblivion at the
power loss...







pgsql-performance by date:

From: Alvaro Herrera
Date:
Subject: Re: Internal operations when the planner makes a hash join.
From: Scott Carey
Date:
Subject: Re: SSD + RAID