headers
Joe Evans | 2 May 2006 14:24
Picon
Favicon

too many files

Dear Managers,

Does anyone know if you can expect performance degradation on a system 
if there are folders with a large number of files in them?

In this case I am talking about 32,000 files.

Tru64 5.1b

Thanks,

--

-- 
Joe Evans, 
Technical Services Manager, 
Management Information Systems, 
King's College London, 
57 Waterloo Road, 
London SE1 8WA 
Telephone:020 7848 3774
Permalink | Reply | 0 comments |
headers
Iain Barker | 2 May 2006 16:38
Favicon

Free AS4100's


We have approx 50x used AS4100 AlphaServers for disposal, plus some unused spares.

Systems are a mix of AC and DC powered units, mounted two per 19" cabinet.

FREE! - buyer must collect from our loading dock, Boston MA area.

Each cabinet contains:

2x AS4100 (AC) or AS4100-CO (DC) each with: 1GB RAM, 1-4x 533MHz CPU, Ethernet, T1/E1/V.35.
2x BA36x SCSI shelf with disks (mix of 18G, 9G and 4G)
2x Memory channel hubs (Mix of MC1 & MC2)
Power distribution etc.

Email me to arrange pickup if you want these.

All will be scrapped next week if there is no interest here.
Permalink | Reply | 0 comments |
headers
Iain Barker | 2 May 2006 19:47
Favicon

SUMMARY: Free AS4100's


Thanks to everyone who responded.

We found one dealer who will take the complete lot.

-----Original Message-----
From: Iain Barker 
Sent: Tuesday, 02 May, 2006 10:39
To: tru64-unix-managers <at> ornl. gov; 'Linux on Alpha processors'
Subject: Free AS4100's

We have approx 50x used AS4100 AlphaServers for disposal, plus some unused spares.

Systems are a mix of AC and DC powered units, mounted two per 19" cabinet.

FREE! - buyer must collect from our loading dock, Boston MA area.

Each cabinet contains:

2x AS4100 (AC) or AS4100-CO (DC) each with: 1GB RAM, 1-4x 533MHz CPU, Ethernet, T1/E1/V.35.
2x BA36x SCSI shelf with disks (mix of 18G, 9G and 4G)
2x Memory channel hubs (Mix of MC1 & MC2)
Power distribution etc.

Email me to arrange pickup if you want these.

All will be scrapped next week if there is no interest here.
Permalink | Reply | 0 comments |
headers
Dr. Martin Körfer | 8 May 2006 10:49
Picon
Favicon

networker

Hi managers,

last week I ran an upgrade from TruCluster V5.1a, PK6 to V5.1B-3,
on a 2-node-Cluster with shared HSG80-storage.
After some difficulties, all runs fine.

Running legato networker 6.1.3, single schedules also worked.

But when starting 2 shedules overlapping (at the same time), I sometimes receive
the following message and some data directories (where starting is tried in the
overlapping time) are not backed up.

* gemini.mpch-mainz.mpg.de:/soft save: RPC error: RPC program or version
mismatch
* gemini.mpch-mainz.mpg.de:/soft save: Cannot open save session with
gemini.mpch-mainz.mpg.de

Here "gemini" is also server and client !

On the firmer version 5.1A those runs worked !

Anybody knows something about those errors ??

Thanks

Martin

--
Dr. Martin Körfer
MPI f. Chemie
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dr. Martin Körfer | 9 May 2006 09:29
Picon
Favicon

summary:networker

Thanks to Roger Dierauer,

as he told me a restart (im my case I could do a "cluster-reboot")
solved the problem.

Thanks

Martin

--
Dr. Martin Körfer
MPI f. Chemie
EDV
J.J.Becherweg 27
D-55128 Mainz

Tel. -49-6131/305541
Fax  -49-6131/3053188

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Permalink | Reply | 0 comments |
headers
Joe Evans | 9 May 2006 17:14
Picon
Favicon

SUMMARY: too many files

This one is difficult to summarise so I have put all the responses below 
for you to look at.

Thanks to everyone that responded.

Joe Evans

*****************************************************************

Dear Managers,

Does anyone know if you can expect performance degradation on a system 
if there are folders with a large number of files in them?

In this case I am talking about 32,000 files.

Tru64 5.1b

Thanks,
**********************************************
Ufs or advfs filessytem??

Advfs should be ok .. Ufs, not sure ..
K

******************************************

Depends on the files and how they've been created. If you've got the
frag file enabled in the domain and your files are relatively small in
nature (or if they're larger but they *all* aren't on even 8Kb size
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Sill | 9 May 2006 18:54
Picon

Administrivia: Tru64-UNIX-Managers information and policy statement

EVERYONE WHO RECEIVES THIS MESSAGE HAD BETTER READ IT THOROUGHLY.

Tru64-UNIX-Managers Information and Rules

This message is a summary of the Tru64-UNIX-managers charter and rules.
Failure to adhere to these guidelines may result in severe chastisement by
the list maintainer and other list participants. Retain a copy of this
statement and refer to it before submitting messages to the list or the list
administrator.

Last modified: 2002-10-09                                                     |

  1. Send only HP Tru64 UNIX (formerly Compaq Tru64 UNIX (formerly            |
     Digital UNIX (formerly Digital OSF/1))) system management questions and  |
     summaries to tru64-unix-managers <at> ornl.gov. Include your return address in
     the body of your message so people can reply directly to you. Avoid MIME
     and HTML--many people can't read them.

  2. This list is not moderated! Every message that is sent to the list will
     be passed on to every member of the list (with a few small exceptions).

  3. This mailing list is managed by a utility called Majordomo. You can
     subscribe to the list by sending a message like:

           subscribe tru64-unix-managers

     to majordomo <at> ornl.gov.

     Likewise, if you want to remove yourself from the list, send the
     message:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roberto Mackun | 15 May 2006 14:49

doconfig fails with "Major number 55 requested in stanza.static f or entry ase_lsm is TAKEN"

Hi Managers,

We have 2 x AS4100 ASE clustered v4.0F servers. 

I successfully installed PatchKit 8 on the first server but I've run into a
problem after installing the PatchKit on our second server. At the doconfig
stage after dupatch had successfully installed all patches it failed with
the error: "Major number 55 requested in stanza.static for entry ase_lsm is
TAKEN". 

Some steps I've taken to attempt to troubleshoot this problem but with no
success:

1. Checked that the /usr/opt/TCR160/sys/stanza.static file is exactly the
same with the other server:
# cksum /usr/opt/TCR160/sys/stanza.static [On Both Systems]
2586267542 1403 /usr/opt/TCR160/sys/stanza.static

2. Checked the existence of /dev/ase and it's major number is 55:
# ls -l /dev/ase
brw-rw-r--   1 root     system    55,  0 May 14 20:37 /dev/ase

3. Built a "base-operating system only" kernel from doconfig, and rebooted
again to single-user mode. "doconfig" still fails with the same error.

4. Tested "mv /dev/ase /dev/ase.bak". "doconfig" still fails with the same
error.

5. Tested recreating the /dev/ase and /dev/rase device files with "mknod"
but doconfig still fails with the same error.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roberto Mackun | 16 May 2006 03:42

SUMMARY: doconfig fails with "Major number 55 requested in stanza .static f or entry ase_lsm is TAKEN"

Hi Managers,

Problem fixed now. HP support found that POPFREA's kernel system file
contained traces of a TruCluster configuration from an older version of the
O/S which were invalid. In the member where doconfig ran successfully
/sys/conf directory contains a file .product.list which contained the
following entries:

# Registration file which contains a one line entry for kernel layered
products
# The format of each line is as follows. Empty lines are ignored. Any line
# with a '#' as the first character on the line is a comment. Other
# entries have the following fields:
#
# Module Path:Subset ID:Date:Company:Product:Version
#
# .........................................................................
/usr/opt/TCR160/sys:TCR160:010712135759:DEC::

Whereas in member where doconfig failed the /sys/conf directory contains a
file .product.list which contained the following entries:

# Registration file which contains a one line entry for kernel layered
products
# The format of each line is as follows. Empty lines are ignored. Any line
# with a '#' as the first character on the line is a comment. Other
# entries have the following fields:
#
# Module Path:Subset ID:Date:Company:Product:Version
#
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jens Kieffer-Olsen | 16 May 2006 13:50
Picon

ES47 i/o way too slow


 A couple of years ago we bought a darned expensive ES47
 with 4 processors and 8 GB ( now 16 GB ) of RAM. To our
 surprise it arrived as a set of two boxes equipped with
 a weird, thick 'umbilical cord' between them for
 communication purposes.

 We had previous very good experience with 4-way ES40 and ES45
 servers. However, from day one the ES47 underperformed.

 It was installed with Tru64 Unix 5.1B-3 by the same HP guy who
 had installed our dozen other Alpha servers. It was installed
 with Oracle 9i the same as our other ES40 and ES45 servers.
 It was equipped with a FCA 2384 HBA using Hitachi HDS 9980V
 SAN disks initially - just like the other servers.

 Immediately the users complained about poor response, but
 managed to compensate by parallellizing their application
 using all available RAM on the server in the process.

 We replaced the HDS disks with HP EVA-5000 disks, but to no
 avail. We upgraded to Oracle 10g using EXPORT/IMPORT, but the
 performance problem persisted. We contacted a HP Denmark expert
 who analyzed runtime logs and suggested changes to cpus_in_rad
 and sched_distance. We installed a second HBA and patched up to
 pk5.

 The poor performance, however, persisted regardless. From inside
 Oracle it is detectable through the file statistics view v$filestat.
 This view is defined as follows:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane