On Wed Jan 27 9:10 , Mark Post mp...@novell.com sent:
On 1/27/2010 at 11:05 AM, Tom Anderson tp...@speakeasy.net wrote:
Wow. That's way too many :)
Course 64K should be enough for anybody.
Remember saying that exact phrase about memory? ;)
Off by an order of magnitude. 640K, not 64K.
on 390 Port [linux-...@vm.marist.edu] On Behalf Of Marcy Cortes
Sent: Monday, January 25, 2010 16:06
To: LINUX-390@vm.marist.edu
Subject: Re: Max # 3390s
Wow. That's way too many :)
Course 64K should be enough for anybody.
Remember saying that exact phrase about memory
Remember saying that exact phrase about memory? ;)
Yeah, that's why I said it, but I forgot the winky smiley thing. ;) ;)
Marcy
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use,
On 1/27/2010 at 11:05 AM, Tom Anderson tp...@speakeasy.net wrote:
Wow. That's way too many :)
Course 64K should be enough for anybody.
Remember saying that exact phrase about memory? ;)
Off by an order of magnitude. 640K, not 64K.
Mark Post
You are the CP//M-80 of evil: Only 64K... not evil enough!
(OK, so that's a modification of You are the MS-DOS of evil: only
640K... not evil enough!)
At least Windows' size qualifies it as evil enough.
- soup
Mark Post wrote:
Tom Anderson wrote:
Wow. That's way too many :)
Course 64K
On Tue, Jan 26, 2010 at 12:16 AM, Mark Post mp...@novell.com wrote:
Does Linux even support that many DASD devices? Does LVM?
Now that I think about it some more, I'm pretty sure LVM has a limit of 256
PVs in a single VG.
Not sure why LVM shows up in the picture. Would you not let Oracle
Rob --
Some might let Oracle have one large raw LV instead of putting a
filesystem on it (instead of giving Oracle plain files). So LVM would
still be in scope even though filesystems not.
LVM is the way to go for managing storage spaces. You can grow an LV
much more easily than a PV. (For some
On Tue, Jan 26, 2010 at 1:29 PM, Richard Troth vmcow...@gmail.com wrote:
Rob --
Some might let Oracle have one large raw LV instead of putting a
filesystem on it (instead of giving Oracle plain files). So LVM would
still be in scope even though filesystems not.
I think you got the
I was thinking of raw devices yesterday... You could just give all those
dasds to Oracle ASM in raw mode.
Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.
On Tue, Jan 26, 2010 at 11:00 AM, Rob van der Heij
On Tue, Jan 26, 2010 at 2:17 PM, Mauro Souza thoriu...@gmail.com wrote:
I was thinking of raw devices yesterday... You could just give all those
dasds to Oracle ASM in raw mode.
Right. But I have no idea about Linux limitations or Oracle issues
with many subchannels.
] On Behalf Of Lee
Stewart
Sent: Monday, January 25, 2010 3:54 PM
To: LINUX-390@vm.marist.edu
Subject: Max # 3390s
Hi all...
We're working with a customer that someone has suggested to them that as
we move their Oracle d/b from brand x to Linux on z, that we also move
the actual d/b from their old SAN
: Monday, January 25, 2010 16:06
To: LINUX-390@vm.marist.edu
Subject: Re: Max # 3390s
Wow. That's way too many :)
Course 64K should be enough for anybody.
I hope we have bigger disk sizes before we need 250,000.
I'd think you'd have a 64K limit under z/VM.
That's still too many :)
Marcy
I think you got the terminology shifted. In linux speak you can put your DB on
- a file
- a block device
- a set of raw devices
To confuse us more, some people refer to the 2nd option as raw
partitions LVM operates in that 2nd layer.
It is likely that you and I are in violent agreement.
On Tue, Jan 26, 2010 at 9:38 PM, Richard Troth vmcow...@gmail.com wrote:
I have been doing Unix since before Linux existed. In traditional
Unix speak, block mode and raw mode are handled by the same
major/minor numbers but making it a block mode special or character
mode special. This is
On Wed, January 27, 2010 09:38, Richard Troth wrote:
I have been doing Unix since before Linux existed. In traditional
Unix speak, block mode and raw mode are handled by the same
major/minor numbers but making it a block mode special or character
mode special. This is inode magic. Linux
Hi all...
We're working with a customer that someone has suggested to them that as
we move their Oracle d/b from brand x to Linux on z, that we also move
the actual d/b from their old SAN box(es) to mainframe disk (3390
images). The catch is that the d/b is about 8TB, and to my rough math
that
On 1/25/2010 at 05:53 PM, Lee Stewart lstewart.dsgr...@attglobal.net
wrote:
The catch is that the d/b is about 8TB, and to my rough math
that seems like 1100-1200 3390 mod 9s.
Does Linux even support that many DASD devices? Does LVM?
I can't say for sure, but I can pretty much
On Mon, Jan 25, 2010 at 03:53:41PM -0700, Lee Stewart wrote:
Hi all...
We're working with a customer that someone has suggested to them that as
we move their Oracle d/b from brand x to Linux on z, that we also move
the actual d/b from their old SAN box(es) to mainframe disk (3390
images).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
or about 150 mod 54s, if I calculate right. That's still a very large
number, but much more manageable. That being said, it's possible that
a direct SAN connection would be faster - at least test it and see for
your application.
Regarding the max
The device drivers manual tells all, but I think the number is somewhere
north of 250,000 dasd devices.
On 01/25/2010 04:53 PM, Lee Stewart wrote:
Hi all...
We're working with a customer that someone has suggested to them that as
we move their Oracle d/b from brand x to Linux on z, that we also
On 1/25/2010 at 05:53 PM, Lee Stewart lstewart.dsgr...@attglobal.net
wrote:
The catch is that the d/b is about 8TB, and to my rough math
that seems like 1100-1200 3390 mod 9s.
Does Linux even support that many DASD devices? Does LVM?
Now that I think about it some more, I'm pretty sure
Subject: [LINUX-390] Max # 3390s
Hi all...
We're working with a customer that someone has suggested to them that as
we move their Oracle d/b from brand x to Linux on z, that we also move
the actual d/b from their old SAN box(es) to mainframe disk (3390
images). The catch is that the d/b is about 8TB
for
your cooperation.
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Rich
Smrcina
Sent: Monday, January 25, 2010 3:15 PM
To: LINUX-390@vm.marist.edu
Subject: Re: [LINUX-390] Max # 3390s
The device drivers manual tells all, but I think the number
. Thank you for your cooperation.
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Lee
Stewart
Sent: Monday, January 25, 2010 2:54 PM
To: LINUX-390@vm.marist.edu
Subject: [LINUX-390] Max # 3390s
Hi all...
We're working with a customer that someone has
immediately by reply e-mail and delete this
message. Thank you for your cooperation.
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Lee
Stewart
Sent: Monday, January 25, 2010 2:54 PM
To: LINUX-390@vm.marist.edu
Subject: [LINUX-390] Max # 3390s
Hi
25 matches
Mail list logo
