For some other points, that are not performance related. IBM i doesn't allow the growing or shrinking of an individual storage space but it does allow them to be removed or added (and at v7.1, without an IPL). So if you can see your environment's capacity requirements changing over time, it's better for you to use more granular sized storage spaces. The suggestions I have seen are to use at least 6 storage spaces.

Patrick Bingham | Principal Power Systems Engineer
Office: 402.965.2381 | Mobile: 402.212.2944 | Patrick.Bingham@xxxxxxxxxxxxx
Sirius Computer Solutions |
14301 FNB Parkway, Suite 400, Omaha, NE 68154

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Friday, June 24, 2011 9:56 AM
To: Midrange Systems Technical Discussion
Subject: Re: Guest Partition Storage Configuration

First: SSDs have their own characteristics that have to be taken into account. I doubt based on the cost of them they would be used to provide virtual storage for a guest partition. That would be a waste of technology in my view.

Your point about back up and recovery is valid, the IFS does have some weaknesses, and back up and recovery speed is one of them.

As to adding space to the partition, create new storage spaces as needed, link them to the guest OS. They will show up there and you add them to the proper ASP the same as you would any other disk unit. If you are using non-standard sizes (50Gb) then add or two or more 50Gb storage spaces and be done with it. I would keep the sizes of the storage spaces consistent.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 6/24/2011 9:13 AM, Jack Kingsley wrote:
ok, how does this convey to the newer SSD??

I see maybe 2 issues with this, you end up having more items to save
per-se with more storage space objects and a longer restore window
since the build time on storage spaces is quite significant from what
I have seen on a restore of them. What about sizing, if in the end
you need additional storage for the storage space that you have
defined, could it come back to cause you issues. Example: I need to
add another 150GB of space to the current 3 spaces defined.

On Fri, Jun 24, 2011 at 10:02 AM, Jim Oberholtzer<midrangel@xxxxxxxxxx>wrote:

Each storage space is presented to the guest partition OS
(regardless of the OS) as a single DASD unit. So in the case you
suggest there would be three disk 50Gb units showing up in the OS.
For Linux or WinDohs, that's sufficient because they do not use
single level storage. For IBM i, it would not provide an I/O
footprint that would allow IBM i to optimize its I/O. Better to
provide 5 units at 35Gb (175 total) than three 50Gb units.
Another small factor in setting up guest IBM i partitions, try to
mimic the same size drives as are supported by the OS. I pick
35GB because there are more total arms, and it is a well known
size. 70Gb are fine as well, however you would only wind up with two or three units, and that could spell trouble for the I/O performance.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 6/24/2011 8:08 AM, Jack Kingsley wrote:
> Just to clarify this then, 1 storage space of 150GB would have
1 disk
arm, 3
> of 50GB each would then possibly use 3?? I really didn't
think about
> aspect of creating storage spaces is why I ask.
> On Fri, Jun 24, 2011 at 8:11 AM, Jim
>> > The reason is to provide IBM i with arms to manage. Creating one
>> > storage space would be the same as giving an IBM i instance only one
>> > disk drive. Bad plan from an I/O performance stand point. The
>> > architecture just works better when it's allowed to do what it is
>> > designed to do.
>> >
>> > Jim Oberholtzer
>> > Chief Technical Architect
>> > Agile Technology Architects
>> >
>> >
>> > On 6/23/2011 3:19 PM, Jack Kingsley wrote:
>>> > > Jim, curious, I never heard of having a storage space only based
>> > 35GB??,
>>> > > could you elaborate on this part. If I need 150GB of space I
would just
>>> > > create 1 storage space.
>>> > >
>>> > > On Thu, Jun 23, 2011 at 4:01 PM, Evan Harris<
>> > wrote:
>>> > >
>>>>> > >> > Yes, the partition will be created with a HMC
>>>>> > >> >
>>>>> > >> > On Fri, Jun 24, 2011 at 12:04 AM, Jack Kingsley
>>>>> > >> > <iseriesflorida@xxxxxxxxx> wrote:
>>>>>> > >>> > > Evan, are you creating this with an HMC or ??
>>>>>> > >>> > >
>>>>>> > >>> > > On Wed, Jun 22, 2011 at 6:21 PM, Evan Harris<
>> > auctionitis@xxxxxxxxx>
>>>>> > >> > wrote:
>>>>>> > >>> > >
>>>>>>> > >>>> > >> Hi Jim
>>>>>>> > >>>> > >>
>>>>>>> > >>>> > >> Thanks again for all the feedback. Your guess
about the memory
>> > may
>>>>>>> > >>>> > >> well be correct - I know the machine in question
did not have
>> > loads of
>>>>>>> > >>>> > >> memory at the time.
>>>>>>> > >>>> > >>
>>>>>>> > >>>> > >> --
>>>>>>> > >>>> > >> Regards
>>>>>>> > >>>> > >> Evan Harris
>>>>>>> > >>>> > >>
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at

This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.

Thank you.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].