Hello,
Thanks to;
BigRedDog <ckrieger_at_latrade.com>
alan_at_nabeth.cxo.dec.com
mortimer_at_physics.uq.edu.au
Steve VanDevender <stevev_at_hexadecimal.uoregon.edu>
Sanford Whitehouse <sanford_at_lsil.com>
Richard Sharpe <admin_at_ns.aus.com>
Patrick Farley farley_at_Manassas1.TDS-GN.LMCO.COM
Regards,
Richard Jackson
Computer Center Lead Engineer
Mgr, Central Systems & Dept. UNIX Consulting
University Computing & Information Systems (UCIS)
George Mason University, Fairfax, Virginia
QUESTIONS/ANSWERS:
---------------------------------------------------------------------
1. Any problems (security, performance, etc.) with running Secure Shell
ssh/sshd?
No reported problems other than it takes longer to login via ssh when
compared to rlogin or telnet. Depending on usage, performance could
degrade.
2. Anyone test the impact of changing an HSZ40 MAXIMUM_CACHED_TRANSFER
parameter from the default 32 to 128 or 256? A knowledgeable Digital
product manager recommends increasing the parameter from the default
to improve overall performance. I have a pair of HSZ40 (dual-redundant)
with 16MB and another pair of HSZ40 (dual-redundant) with 32MB.
Of course, it depends. Try it.
3. Is the HSZ50 a seamless upgrade over the HSZ40? Is it true the HSZ50
is replacing the HSZ40? Does the HSZ40 and HSZ50 run the same HSOF
firmware?
The HSZ40 is being phased out and the de facto replacement will be the HSZ50.
Digital even offers an upgrade offer at
http://www.digital.com/info/CU4207.
The HSZ40 and HSZ50 use different firmware.
4. The 4.0x and the 3.2G AdvFS OSF375-350324 contain a version of mkfdmn
that supports Bitfile Metadata Table (MBT) preallocation. This option
appears to eliminate BMT fragmentation. For example,
mkfdmn -p 28800 -x 1024 /dev/rzb25c rzb25c_domain. Any known problems
with preallocating the BMT in general?
There are no reported problems with preallocation. A AdvFS knowledgeable CSC
engineer recommends to use mkfdmn's -p instead of -x. That is, it is better
to preallocate than use large page sizes on extents, in general. For example,
mkfdmn -p 28800 /dev/rzb25c rzb25c_domain
may produce better results than
mkfdmn -x 1024 /dev/rzb25c rzb25c_domain
---------------------------------------------------------------------
RESPONSES:
---------------------------------------------------------------------
BigRedDog <ckrieger_at_latrade.com>:
:3. Is the HSZ50 a seamless upgrade over the HSZ40? Is it true the HSZ50
: is replacing the HSZ40? Does the HSZ40 and HSZ50 run the same HSOF
: firmware?
As best as I can tell, the firmware is not compatible between the two.
Regarding a seamless upgrade. We had an HSZ40 for a few months while
waiting for our HSZ50. We elected to not try to save our data, but the
manual seemed to indicate that it was possible. You need to look at
the "SET device-name TRANSPORTABLE" command. Your skills and knowledge
are truly seamless in the upgrade process since the commands are
essentially identical. Even if the HSZ50 is not replacing the HSZ40, I
would make the change anyway because of the larger amount of write-back
cache available.
---------------------------------------------------------------------
alan_at_nabeth.cxo.dec.com:
2. Haven't tried it, but... As always it depends on what
you're doing. The HS family doing read caching is only
useful if data isn't in whatever host cache are used;
buffer cache or database cache AND the data is still
in the HS cache. If your software is using raw disks
then the HS cache has a much better chance of being
useful because there won't be any UBC caching. If
all your reads to the device are small, then using a
larger MAXIMUM_CACHED_TRANSFER probably won't help
and could hurt, by caching data you're rarely read
back. If it happens that your I/O load is doing large
I/Os AND there is a good chance that the data you want
will still be in the cache, then the larger value may
save having to do some I/O.
When in doubt; benchmark.
3. If the folks upstairs did their job, it should be...
It wouldn't surprise me that there will come a time
when you can't buy a new HSZ40 of any flavor, except
used. It may happen that at the same time this is
the case, the HSZ50 will still be available.
At some point, nearly everything is being replaced by
something newer. It is what drives the industrial
revolution...
The HSZ40 and the HSZ50 do not run the same version
of firmware. There are bound to be far more common
parts of the original source code than differences
however.
4. When pressed I doubt anything can eliminate the problem
of BMT fragmentation or worse running out of BMT extents (*).
But, easy preallocation is a vast improvement over having
to preallocation by hand; create millions of files, delete
millions of files. If you can accurately predict how many
files you need and preallocate accordingly, then you will
get very close to eliminating the problem.
(*) Ok, making the BMT extent map more extendible
than the BMT will solve this particular problem.
---------------------------------------------------------------------
mortimer_at_physics.uq.edu.au:
> 1. Any problems (security, performance, etc.) with running Secure Shell
> ssh/sshd?
We're running ssh here without any problems. The only noticeable
performance difference is that ssh logins take longer than rlogin
or telnet logins. After you've logged in there's no noticeable
difference. Your mileage may vary though.
---------------------------------------------------------------------
Steve VanDevender <stevev_at_hexadecimal.uoregon.edu>:
> 1. Any problems (security, performance, etc.) with running Secure Shell
> ssh/sshd?
Nope. We use it on several systems and have noticed essentially no
system impact.
You should get ssh 1.2.18 if you are running C2 security. It has better
support for OSF C2 security in recent versions of Digital UNIX.
---------------------------------------------------------------------
Sanford Whitehouse <sanford_at_lsil.com>:
If you use ssh/sshd for X11 forwarding and you have encryption on
the performance hit can be very large. I suggest you test it,
if you intend on using it. You're mileage may vary.
---------------------------------------------------------------------
Richard Sharpe <admin_at_ns.aus.com>:
>1. Any problems (security, performance, etc.) with running Secure Shell
> ssh/sshd?
>
Can't answer your other questions, but I have installed ssh (sshd) on a
customer's Alpha machine running 4.0b, and all seems OK. In fact I am logged
in now from my laptop while I send this email ... I am using the win95 ssh
client.
I did have to build with cc rather than gcc, but I think that that wass
because gcc had not been installed properly.
---------------------------------------------------------------------
Patrick Farley farley_at_Manassas1.TDS-GN.LMCO.COM:
> 1. Any problems (security, performance, etc.) with running Secure Shell
> ssh/sshd?
>
We are using Secure Shell quite effectively. Been using it for about 4 months.
Never had a problem.
---------------------------------------------------------------------
Received on Fri Jul 18 1997 - 20:32:07 NZST