ok jim, thanks for the information.

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

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
with more storage space objects and a longer restore window since the
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
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

Each storage space is presented to the guest partition OS (regardless
the OS) as a single DASD unit. So in the case you suggest there
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
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
two or three units, and that could spell trouble for the I/O

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
arm, 3
> of 50GB each would then possibly use 3?? I really didn't think
> aspect of creating storage spaces is why I ask.
> On Fri, Jun 24, 2011 at 8:11 AM, Jim Oberholtzer<
>> > 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
>>>>> > >> >
>>>>> > >> > On Fri, Jun 24, 2011 at 12:04 AM, Jack
>>>>> > >> > <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,
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 thread ...


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

This mailing list archive is Copyright 1997-2019 by midrange.com 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].