get process id

[Bill Vermillion]

On Sun, Oct 10 18:49 , while denying his reply is spam, Fairlight 
prattled on endlessly saying: 

> Is it just me, or did Bill Vermillion say:
> > 
> > But not on the beast.  Looking at currently running processes
> > and performing   grep ^8  on a ps -ax yields this:

> > 88166  ??  I      0:00.02 sshd: bv [priv] (sshd)

> > Just FYI.  The inode numbers that are over a million usually take
> > a second look to get them correct too.

> > Much of 'beastie' has been 64 bit for a few years now.   

> And UW 7.1 with Non-Stop Clustering (NSC, now defunct and
> discontinued--not that it worked exactly correctly unless you
> specifically recompiled OSR5 binaries with the UDK) not only
> -used- 60000+ PID-space, it actually -started- PID's above
> the range of a regular PID's length on a 32bit system. Any
> processes forking would not work correctly due to the returning
> PID value being out of range. Ugh.

Well the OSR5 was getting to be pretty limited - and by the time
UW7 came out all other vendors for Intel were at a real SysV4 -
with Dell pushing theirs quite hard - for a while.

> Solaris, OTOH, has been 64bit on Sparc for...well wasn't
> Sparc always 64bit? And our PID's roll somewhere around the
> 30-32K range on the 5.7 and 5.8 systems here. Not sure how
> tunable that is, nor do I intend to ask, since it makes little
> difference. Just saying, 64bit OSes don't necessarily mean
> that everything is written or configured to utilise the full
> resources available.

Well a PID of under 64K doesn't even fill 16 bits :-)

And the beast really only is a true 64 bit for the Alpha, IA64,
AMD64, and Sparc 64 architectures as far as I can tell.  The PC98
architecture appears to be strongest in Japan on the NEC
architecture.

The base design of OSR5 is pretty limited - but for those who
don't have large requirements - which is where a lot of OSR5 is
used - that's not a problem.

So many of the older *n*x didn't use the 32 bits available 
for many things they could have.  That was probably because of
their migration out of the 16-bit world.   And for years
PIDs under 30K and inodes under 64K weren't a problem.  But
since the arrival of very cheap individual hard drives - and 
add-on arrays in the 3TB size for list of $10K from vendors knows
to not shave prices - things are moving along rapidly.

I remember when you had to be able to boot systems in the first
512MB, then it got moved to the boot FS had to reside in the first
1024 cylinder, the the first 2GB.  The beast in the 5.x series
boot requuirement is the boot code must reside in the first
1.5 terabytes of file system space.   Ten years ago only the
largest companies had over a TB of storage.  Now over 100TB
is happening.  Sears - when they decided to track and then do more
analysis figured their 5-7TB of storage would move to about 70TB.

Things are getting larger by the moment.

Bill

-- 
Bill Vermillion - bv @ wjv . com