Hi,

Is there a performance issue with running Pick (D3 Linux) accross 2
separate (i.e. one is sda7 and the other is sda9) partitions?

I want to add an effectively spare partition rather than re-installing
the whole box (before you ask the obvious "why the hell would you want
to do that" question)

I assume I will want to do a dummy file-save, resize, file-save and
reload to ensure optimum space usage.

Also, if I add the disk space manually in pick0 or with D3_setup, will
I need to reactivate?

Thanks in advance,

Jon

No need to re-activate

No problem with spanning multiple partitions ... depending on the
version partitions may need to be <2Gb, but these days 1Tb is AOK

HOWEVER, if you allocate D3 to both partitions, YOU will not control
how/where/when things are allocated --> D3 virtual just sees this all
as 1 big play ground.

You MIGHT need a re-install/serialize if you installed an additional
disk drive, but assigning additional partitions isn't an issue (apart
from "possible" 2Gb limit noted above)


jmembrey (AT) hotmail (DOT) com wrote:

If I'm not mistaken, multiple partitions are simply additive. Up to a
given frame you're in one partition and after that you're in another.
You can add as many partitions as you want to a D3 volume. I think
when I was doing QA way back when we experimented with up to 64
partitions, and they weren't contiguous.

Adding a new partition is the standard procedure for adding disk space
to your D3 space, and there's no need to re-install, just add the
volume to pick0 and reboot. You don't get a performance benefit
unless the new partition is is on another disk, and even then the
space actually needs to be used. That is, if you're using the other
disk/partition then you're using another disk head, but if all of your
access is in the lower end of the system then you aren't using that
other head. You could get a tiny performance hit if you span the D3
space across a physical disk volume and cause the heads to jump around
for the simplest of disk operations, but I don't think this is a big
deal with modern disks. At some sites we used to do our own disk
management, building the D3 virtual disk using volumes like hda3,
hdb3, hda4, hdb4, etc. The idea was to provoke hard disk access on
multiple physical volumes to get the performance benefit. The risk
here is that if one volume goes bad then the whole thing is bad -
which brings in RAID...

I have no idea what sort of LVM facilities are available in the
current releases of Linux - consider this more of a historical view of
how things could be done. I have (at least) one client that uses some
sort of LVM software to allocate disk for OS, DBMS, RAID, etc. - I
dunno where it came from or how it works.

HTH
T

"Ross Ferris" wrote:

Thanks guys - I'm doing this for minimum hassle so it looks like just
adding the space will do the trick.

D3_setup or manual addition to the /usr/lib/pick/pick0 file?

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Here is one area that shows a significant advantage in the FSI. You simply
tell D3/NT which partition to create the new accounts in. I presume that
this will be the same for Linux when the FSI comes out. Optimist aren't I?
Peter McMurray

Excalibur wrote:
I remember a few years ago, when RD were first talking about "Version
8" and adding support for FSI, attending a presentation by Jim Idle,
looking at jBase futures (and the rewrite using Java)

At the time Jim commented that physical file I/O through the underlying
OS was becoming "a bit of a limiting factor in high load environments",
and passed a comment along the lines of RD had done the right thing
(for a change) doing their own RAW I/O and this was something he would
be looking at.

As chance would have it, the people involved with these projects at
both camps de-camped, but I for one am NOT looking forward to anything
like the FSI being introduced to an otherwise stable platform !

Ross Ferris
Stamina Software
Visage > Better by Design!

jmembrey (AT) hotmail (DOT) com wrote:

Over the years D3 *nix platforms have been enhanced to ignore some
changes to pick0 after the system has been booted while reading
others. Gosh I hope I'm right about this but as of somewhere in 7.2 I
think we could update almost all fields in pick0 with impunity, even
from the update processor while D3 is up, then just shutdown/reboot to
have the new changes take effect. There is no need to run D3_setup.

Of course you should always have at least one (get two!)
complete/verified!!! file-save before performing even a simple
operation like this. If you get the disk info wrong, D3 might reset
maxfid and other params and everything will get toasted. Get those
numbers right.

Doveryay, no proveryay...
"Trust but verify"
T

"Tony Gravagno" wrote
floppy files temporarily, if you're intent on using d3-setup; I have
fading but unhappy memories of setup nuking my pseudo tape data
back to zero length. Think maybe was on windows, but not sure.