raw disks
Neil Truby
SCO Openserver 5.0.5
In some flavours of UNIX, notably Solaris, it is imperative that a small
offset is used on the first slice on a disk if that slice is used as a raw
device for Oracle or Informix or something, i.e. not for a file system.
This is because the raw data can will otherwise over-write the disk's VTOC.
Other flavours, for example HP-UX, are intelligent enough to avoid this.
Into which camp does SCO fall?
thanks
Neil
Gary Quiring
I use Informix 7.3x on SCO OpenServer 5.05 and 5.06 with raw partitions. It
works fine. You can use an offset in onmonitor to avoid the first few bytes.
The main problem with SCO and Informix is the number of partitions you can have.
Fdisk will allow 4 and divvy will allow 7. 28 2gig chunks is the limit. It's a
big problem on larger systems. I moved my main DB server to Solaris so I can
use Veritas volume manager.
Gary Quiring
John Gray
Open server isn't limited to 2 Gig divisions nor fdisk partitions.
I won't argue with the volume manager though.
-john
Neil Truby
It
> works fine. You can use an offset in onmonitor to avoid the first few
bytes.
Thanks. I know I can use an offset. But my question is "Do I need to?".
--
Neil Truby t:01932 724027
Director m:07798 811708
Ardenta Limited e:neil....@ardenta.com
"Gary Quiring" <gqui...@msn.com> wrote in message
news:fce4aug8t01267a7c...@4ax.com...
Bela Lubkin
None of the above.
If you have a disk that you wish to entirely dedicate to a raw store,
use the whole-disk device (/dev/rhd30, /dev/rdsk/3s0, or similar). You
will indeed overwrite the partition table and so on, but that's OK: if
you're using the entire disk as a raw store, it has no use for such
things.
If you only want to use part of a disk as a raw store, dedicate an
entire partition (/dev/rhd32, /dev/rdsk/3s2, or similar); or use `divvy`
to create and name a division, and use that. In using an entire
partition you will overwrite any division table that may have existed,
but again, you don't need one. In using an entire division you will
overwrite any filesystem superblock, or other data, that used to exist
there, but you don't need those.
If you use an entire disk or an entire partition, OpenServer's software
badtracking (for IDE disks) or badblocking (for SCSI disks) will be
disabled. I am not sure this is a negative at this point -- these days,
disks either have no user-visible bad blocks, or they are garbage.
>Bela<
Neil Truby
The rdbms in question is Informix, which has an upper limit of
(slice+offset) of 2Gbytes, so use of the entire disk is not a viable option.
I remain unclear whether, if I use the *first* partition on a disk, I risk
over-writing some disk-wide vtoc info that file systems or other partitions
on the disk may have needed.
However, if I'd asked this question on the solaris newsgroup I'd have
received scores of replies saying it was a problem, which itself leads me to
suspect that it isn't on SCO.
"Bela Lubkin" <be...@caldera.com> wrote in message
news:2002032821...@mammoth.ca.caldera.com...
Bela Lubkin
> Thanks.
> The rdbms in question is Informix, which has an upper limit of
> (slice+offset) of 2Gbytes, so use of the entire disk is not a viable option.
Surely it must support using multiple raw partitions? If you use
OpenServer's partitions & divisions to their fullest, you can have 28
divisions on a disk == 56GB. Ok, won't let you use all of a reasonably
big current disk, but you can have 54GB of 2GB raw divisions + one big
Unix filesystem on the rest...
> I remain unclear whether, if I use the *first* partition on a disk, I risk
> over-writing some disk-wide vtoc info that file systems or other partitions
> on the disk may have needed.
Nothing special about the first partition. Of course you have to use
the right device names -- /dev/rhd?[1-4] (/dev/rdsk/?s[1-4]) are
partitions 1-4, /dev/rhd?0 is _whole disk_... you could be tricked by
the seeming continuity of the names. If you overwrite "partition 0",
i.e. the whole disk, you do lose all the partitions.
> However, if I'd asked this question on the solaris newsgroup I'd have
> received scores of replies saying it was a problem, which itself leads me to
> suspect that it isn't on SCO.
It's fine.
I recommend using divisions, for maximum flexibility.
>Bela<
QMan
wrote:
>> The main problem with SCO and Informix is the number of partitions you can have.
>> Fdisk will allow 4 and divvy will allow 7. 28 2gig chunks is the limit. It's a
>> big problem on larger systems. I moved my main DB server to Solaris so I can
>> use Veritas volume manager.
>>
>> Gary Quiring
>
>Open server isn't limited to 2 Gig divisions nor fdisk partitions.
>I won't argue with the volume manager though.
John, I never said OpenServer was limited to 2 gig partitions,
Informix IS!!!! That is why you need a large amount of 2gig slices to
run a raw file system with Informix. My Solaris 7 server has over 200
2 gig partitions. It's a joke, but that is the way of life when using
Informix.
Gary Quiring
QMan
<neil....@ardenta.com> wrote:
>> I use Informix 7.3x on SCO OpenServer 5.05 and 5.06 with raw partitions.
>It
>> works fine. You can use an offset in onmonitor to avoid the first few
>bytes.
>
>Thanks. I know I can use an offset. But my question is "Do I need to?".
NO.
Gary
Dave Dickerson
wrote:
[snip]
>
>If you use an entire disk or an entire partition, OpenServer's software
>badtracking (for IDE disks) or badblocking (for SCSI disks) will be
>disabled. I am not sure this is a negative at this point -- these days,
>disks either have no user-visible bad blocks, or they are garbage.
>
>>Bela<
Bela...does this mean I can skip the 3 hour thorough-destruct badtrack
in my procedures for installs/reinstalls on a new hard disk?
DDinAZ
Bela Lubkin
> On Fri, 29 Mar 2002 05:57:11 GMT, Bela Lubkin <be...@caldera.com>
> wrote:
> >If you use an entire disk or an entire partition, OpenServer's software
> >badtracking (for IDE disks) or badblocking (for SCSI disks) will be
> >disabled. I am not sure this is a negative at this point -- these days,
> >disks either have no user-visible bad blocks, or they are garbage.
>
> Bela...does this mean I can skip the 3 hour thorough-destruct badtrack
> in my procedures for installs/reinstalls on a new hard disk?
It's up to you... the badtrack scan _tells_ you whether the drive is
clean or is garbage. You can choose to assume every drive is clean;
you'll be right most of the time.
And I'm being too absolutist about it. I'm sure even today, you'll
sometimes get a drive from the factory with a few bad blocks, due to
shocks during shipment. badtrack will hide them.
>Bela<
Dave Dickerson
I'll spend the 3+ hours if it's a new drive. Thanks!
DDinAZ
Brian K. White
"Neil Truby" <neil....@ardenta.com> wrote in message
news:pSYo8.7373$Vm5.61492@NewsReader...
> Thanks.
> The rdbms in question is Informix, which has an upper limit of
> (slice+offset) of 2Gbytes, so use of the entire disk is not a viable
option.
> I remain unclear whether, if I use the *first* partition on a disk, I
risk
> over-writing some disk-wide vtoc info that file systems or other
partitions
> on the disk may have needed.
> However, if I'd asked this question on the solaris newsgroup I'd have
> received scores of replies saying it was a problem, which itself leads
me to
> suspect that it isn't on SCO.
you can use the first (of a possible 4) "fdisk" partition, raw, all of it,
and it will not touch the disk-wide partition table.
you can use the first (of a possible 7) "divvy" partition within any fdisk
partition, and it will not touch the divvy table that describes the other
divvy partitions in that fdisk partition, nor will it touch the disk-wide
partition table or any other divvy tables.
it all depends what device nodes you use
what you _can_ do that is dangerous, is if you have several partitions on
a disk, and some of them you need to keep alive, and some you want to use
raw,
it is possible for you to write data to device /dev/rdsk/1s0 which is a
device node for the whole raw scsi disk 0, and if you write data to the
very beginning of that device, you will indeed trash your partition table.
the reason it's "not a problem" on SCO, is that you don't need to
calculate your own offsets to avoid trashing the partition table or divvy
tables. All you have to do is NOT use the raw disk device. Use one or more
fdisk partition devices, or one or more divvy partition devices.
<html><body><pre>
disk 0 --+--fdisk 1--+--divvy 1
| +--divvy 2
| +--divvy 3
| +--divvy 4
| +--divvy 5
| +--divvy 6
| +--divvy 7
|
+--fdisk 2--+--divvy 1
| +--divvy 2
| +--divvy 3
...
+--fdisk 4--+--divvy 1
...
+--divvy 7
/dev/rdsk/0s0--+--/dev/rdsk/0s1--+--/dev/userdefined 1
| +--/dev/userdefined 2
| +--/dev/userdefined 3
| +--/dev/userdefined 4
| +--/dev/userdefined 5
| +--/dev/userdefined 6
| +--/dev/userdefined 7
|
+--/dev/rdsk/0s2--+--/dev/userdefined 8
| +--/dev/userdefined 9
...
where "userdefined *" is something you make up when you run divvy.
you could name them after the informix database and number them or
something.
In this case you would surely use only divvy partition device nodes, since
your disks are surely larger than 8 gig and you need more than 4
partitions.
more specifically, in the example case of scsi disk 0, if you just avoid
writing to device major number 1 minor number 0 (whole disk)
or 1,15 1,23 1,31 1,39 (fdisk 1 2 3 4)
and just write to things like:
1,40 1,41 ... 1,46 (disk 0, fdisk 1, divvy 0-6)
Since you could make device nodes by any name you wish but this is the
part that really matters of course.
Also this was a BAD example since very likely disk 0, fdisk 1, divvy 0 is
your BOOT PARTITION! so don't use these exact examples!
also watch out for a few other wierd "devices" that sco has which map back
to some of these, like sco has devices complete with their own major &
minor numbers that might go to any physical location, since they go to
things like "active partition" and "boot partition" and "swap partition"
here is the relevant man pages to figure out the device names and
major/minor numbers, but you can glean them from running divvy and ls on
your system too.
http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?divvy+ADM
http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?hd+HW
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani