Re: SSD Analyzer Tool

The documentation lists several ways to do this. Start there.
Something about doing a TRCASPBAL first and then doing a STRASPBAL
TYPE(*HSM)
You can screw that up by running one of the other STRASPBAL options.

The sturdiest manual way is to put the SSD's on a separate ASP. My boss
wasn't keen on that because that starts to tie up disk space versus
spreading the load.

Another way is to determine what data you want to get the best performance
on and run CHGPF and tell it to use SSD (or unit 255 on older OS). Then
after doing so certain file operations will then physically move the data.
Stream files are done differently.

We went with the latter. Basically we got the drives to make month end
faster. The fact that the OS really wanted to put some Domino data there
first (HSM) would not have helped month end.



Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jack Kingsley <iseriesflorida@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 12/01/2011 09:38 AM
Subject: Re: SSD Analyzer Tool
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Can you explain how you moved the heavy I/O to the SSD's, were they
mirror'd or raid, does it matter.

On Thu, Dec 1, 2011 at 1:03 AM, Pete Massiello - ML <
pmassiello-ml@xxxxxxxxxxxx> wrote:

Joe,

I put some SSDs in a Power6 520 2 years ago, it is an I/O

intensive

machine. We moved all the heavy I/O files to the SSDs, performance is
great, and we haven't replaced one SSD yet. I enjoyed reading all your
technical specs, just reporting what I have out in the field.

Pete

Pete Massiello
iTech Solutions
http://www.itechsol.com


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Thursday, December 01, 2011 12:40 AM
To: Midrange Systems Technical Discussion
Subject: Re: SSD Analyzer Tool

"Reliable enough" leaves a whole lot of room. The problem with
reliability is the number of charge states required per cell. SLC

devices

store one bit per cell and so you either need on or off; it's pretty
simple. MLC devices typically store two bits per cell, and so require

four

identifiable states and those degrade pretty quickly. The numbers I've
seen are somewhere around between 3000 and 10,000 writes (as opposed to
100,000 for SLC). That's NOT a lot of writes unless you have a really,
really good load leveling algorithm. Not to mention MLC is much slower.

I

think IBM uses eMLC, which is a compromise design with more writes but

is

even slower still especially on writes.

So, back to the question at hand, what's "reliable enough"? We update

our

item master with every shipment. We ship hundreds of times a day.
To have cells die after a few thousands writes is awfully frightening.
On the other hand, for a mostly read-only drive like a load source

there's

something to be said for SSD. I'm designing my next workstation and I

may

go with two different SSD drives, one for boot / program load and one

for a

scratch drive (things like workspaces for my Rational products). The
thought is that the scratch drive can be replaced as needed without
affecting the load partition, and I'll have a traditional hard drive to
store low-priority data and also to back up the SSDs.

Joe

The original 70GB SSDs were SLCs as I recall. These were actually
128GB devices leaving significant capacity for re-maping worn out

areas.

The current 177GB SSDs are MLC devices. I don't have information on
the overcapacity of these devices but suspect perhaps 256GB is the

likely size.

IBM would not ship an enterprise class device on POWER systems if they
did not believe that they were reliable enough for the task at hand.

- Larry "DrFranken" Bolhuis

On 11/30/2011 10:18 PM, Joe Pluta wrote:

What kind of SSDs are they? SLC or MLC? Any information on how long
they last? Because the MLCs are notoriously short-lived. A lot of
that depends on the data use algorithms.

Joe

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.