MCP with SSDs?? somebody worked on this kind of system?? Pros & cons??

[Andres Abello]

[Paul Kimpel]

There have been various third-part Solid State Disk systems available
for MCP systems over the years, starting in the early 1980s. All of the
ones I have seen (none recently) have been battery-backed RAM designs,
not the flash-based storage we generally associate with SSD today.

I see no technical reason why current SSD technology would not work with
MCP systems, but there could be marketing or support restrictions. It
would probably depend who you are getting the storage from and how it
connects to the rest of the system.

As far as I know, all flash-based storage has a limited number of write
cycles. That probably numbers in the hundreds of thousands, at least,
for current flash chips, but I would be wary of using it for highly
volatile data applications. Flash is usually characterized by lower
latency and higher transfer rates than hard disks, and lower power
requirements, but relatively slow write times. That also argues against
it for use with volatile data or high levels of update activity.

If this interest in SSD is in response to the disk troubles you had a
few weeks ago, then SSD is no panacea. Any type of storage can fail. The
only effective form of data protection is redundancy, coupled with
regular backups.

--
Paul

[Scott Lurndal]

Paul Kimpel <paul....@digm.com> writes:
>There have been various third-part Solid State Disk systems available
>for MCP systems over the years, starting in the early 1980s. All of the
>ones I have seen (none recently) have been battery-backed RAM designs,
>not the flash-based storage we generally associate with SSD today.

There were a couple of third party companies that sold these in the
80's into medium systems sites - they interfaced to 5N-DLP's if I
recall correctly.

>
>I see no technical reason why current SSD technology would not work with
>MCP systems, but there could be marketing or support restrictions. It
>would probably depend who you are getting the storage from and how it
>connects to the rest of the system.

I think the biggest issue for large (A-series) systems would be the 180-byte sector
size - while you can reformat a spinning SCSI drive to 180-byte sectors
with the right tools, I've never seen a flash-based SSD that allowed
alternate sector sizes (other than 512-byte and 4096-byte).

(although maybe A-Series MCP now supports 512-byte sectors ??)

>
>As far as I know, all flash-based storage has a limited number of write
>cycles. That probably numbers in the hundreds of thousands, at least,
>for current flash chips, but I would be wary of using it for highly

However, all the modern flash controllers include wear-levelling
firmware to ensure that the wear is distributed across all the flash
cells (SLC or MLC). That significantly increases the lifetime of
drives with this technology such that it would be acceptable even
for highly volatile applications.

>volatile data applications. Flash is usually characterized by lower
>latency and higher transfer rates than hard disks, and lower power
>requirements, but relatively slow write times. That also argues against
>it for use with volatile data or high levels of update activity.

Slow is relative. It's still considerably (orders of magnitude) faster
than spinning media.

>
>If this interest in SSD is in response to the disk troubles you had a
>few weeks ago, then SSD is no panacea. Any type of storage can fail. The
>only effective form of data protection is redundancy, coupled with
>regular backups.

Now that's truth.

Once PCM and/or MRAM replace flash in SSDs, you'll see them more
widely deployed, I think.

PCI-express based flash cards for servers (Violin Memory and
Fusion-IO are the big players, but there are dozens of vendors
entering this space) are quite popular, particularly for database
servers. Unfortunately these require special host operating system
drivers which are particular to the vendor. This will change as
vendors adopt the NVM Express standard.

scott

[timca...@aol.com]

The 6xx, 7xx, & 8xx systems will talk to a SATA SSD via the SAS IOP (it was
qualified at one point, not sure what the status is now). If you're putting a
disk rack out there with a bunch of SSDs behind an FC translator it will depend
on the box you put them in how compatible it is.

As others have mentioned, always backup your data. :)

- Tim

[Marc Wilson]

In comp.sys.unisys, (Scott Lurndal) wrote in
<Pe9Rs.62$KO...@fe31.iad>::

>Paul Kimpel <paul....@digm.com> writes:
>>There have been various third-part Solid State Disk systems available
>>for MCP systems over the years, starting in the early 1980s. All of the
>>ones I have seen (none recently) have been battery-backed RAM designs,
>>not the flash-based storage we generally associate with SSD today.
>
>There were a couple of third party companies that sold these in the
>80's into medium systems sites - they interfaced to 5N-DLP's if I
>recall correctly.
>
>>
>>I see no technical reason why current SSD technology would not work with
>>MCP systems, but there could be marketing or support restrictions. It
>>would probably depend who you are getting the storage from and how it
>>connects to the rest of the system.
>
>I think the biggest issue for large (A-series) systems would be the 180-byte sector
>size - while you can reformat a spinning SCSI drive to 180-byte sectors
>with the right tools, I've never seen a flash-based SSD that allowed
>alternate sector sizes (other than 512-byte and 4096-byte).

On 2200 systems, there is a similar issue with sector sizes etc, but the
drives used have long been essentially commodity SATA disks in redundant
arrays with an interface layer that pretends to be whatever logical
layout required.

Indeed, most "disk" used in the machines I've worked on recently has
been EMC (or similar) disk emulating whatever is needed.
--
Marc Wilson

Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Fax: (44/0) 844 779 0968 Mobile: (44/0) 7973 359850
Skype: cleo-marc Mail: enqu...@cleopatra.co.uk
Web: http://www.cleopatra.co.uk
Registered in England and Wales no: 2588943 VAT Reg: 561 1182 69
Registered office: St George's House, 215-219 Chester Road
Manchester M15 4JE

https://plus.google.com/100816173414569062406
_________________________________________________________________
Try MailTraq at https://my.mailtraq.com/register.asp?code=cleopatra

[Ex-FE]

The MCP 180 sector size is long gone with the VSS1 or VSS2 emulation by
the IOP. In VSS2 mode it stores 360 bytes (2 x 180) in every 512 byte
sector. VSS1 mode uses the full 512 bytes of a disk sector by storing
(2 x 180) and then spliting the next 180 bytes across into the next
sector. VSS2 mode is faster but wastes 152 bytes of 512 bytes or 29%.

I believe some new EMC disk arrays with SSD have been qualified on the
newer MCP machines.

EX-FE




sc...@slp53.sl.home (Scott Lurndal) wrote in
news:Pe9Rs.62$KO...@fe31.iad:

[dkal...@gmail.com]

I suppose if you were sufficiently motivated, you could write a control layer which:
1) Did wear-leveling
2) Did grooming
3) Converted 180-byte sectors to 4096
4) Did guaranteed write-caching

That is... a large task. But do-able.

[Andres Abello]

Thanks!!