SUMMARY: Netra NFS woes

Date: Wed Sep 17 1997 - 07:00:52 CDT


Thanks for all the replies. It seems that using Disksuite logging may be
a good thing to avoid potential fsck delays. We're a bit nervous about
twiddling with the, and will probably leave off such changes 'till
next vacation.

With some care, the CLI can be used to administer the system in the usual
Solaris2 way.

Regards to all,

Gordon Robertson, Central Systems Manager,
                                Infrastructure Systems Division,
Tel +44(0)224 273340 Directorate of Information Systems
E-Mail : and Services,
                                Aberdeen University, Aberdeen AB24 3FX, U.K.

Here are summaries of the replies, followed by the original query:-

>>From: Jeff Wasilko <>

> More than likely, it's using UFS logging, which should keep you
> from having to fsck (it just replays transactions from the log
> instead of fsck'ing). You can check if UFS logging is being used
> by looking at the output of metastat. Look for 'trans' devices.

There were none. Just devices d0 (the raid 5 array), and hsp000
(the hot spare).
But we're now looking at SDS to see how to set up logging.

>>From: Singh Adrian <>

> when you change hostname without reconfiguring you also
> have to change the name in the three /etc/net/tic*/hosts files
> and the /etc/hostname.??? file (where ??? is interface name)
> and update the /etc/hosts file with new name/IP addr.

We've also discovered some Networker files under /export/admin/nsr where
names need changed, and Networker is now behaving OK.

>>From: Stefan.Fruntke@Germany.Sun.COM (Stefan Fruntke)

Suggested that we should look at SDS journalling, and also to look at the
Veritas software (vfs) bundled with Solaris 2.6. which also uses journalling.

We're presently awaiting 2.6, and will be interested to see if it can be
used on the Netra system.

>>From: Shriman Gurung <>

Pointed out the need to be aware that many "standard" Solaris files have
corresponding netra-specific files which need to be kept in line.

>>From: (Marc S. Gibian)

Also suggested using SDS journalling to avoid potential fsck problems

>> Andrew Norrie <>

Pointed out Bug Id: 4057520 which has a workaroung for the quotacheck problem.
We've now got ~8k users installed on the netra, and quotacheck with the
workaround takes ~12mins, which is OK for us.

Andrew is still having quota problems (crashing) under load, and the
only solution is to turn quotas off. We wont hit a significant load for
another two weeks. We'll leave quotas on and see how things go.

Original Query:
>From sys013 Fri Sep 12 17:07:50 1997
Subject: Netra NFS woes
X-Sun-Charset: US-ASCII
Content-Length: 2279


We're having problems with a new Netra NFS (Smartserve 1.1). With very little
human intervention (a GOOD thing) it has configured itself a marathon 38Gbyte
/export partition (a BAD THING, I think).

We got a bit scared about how long fsck and quotacheck might take, so I did a
simple test on a few megs. We estimate about 16hrs each when we get the
users' files over. This seems more-than-a-bit much. But Sun (hotline)
maintains this is the way to do it! They were not forthcoming about how we
might load the filestore from the old servers, or establish quotas. They told
us we may only use the browser interface if we want support. This (interface)
is a bit primitive. So you cant do things like deleting departed user's
files for example. Nor change file permissions or ownership. The "close
down" option calls shutdown which tries to rwall to PC clients - which
probably arn't even switched on. Closing down is even slower than fsck-ing.
We have over 700 PC's and ~8000 users to serve.

Has anyone been here? If so are there any work arounds? I'd like to just
disregard the browser and get on with the familiar Solaris2 CLI. Is anyone
doing this? Where are the pitfalls? So far we've written a program to load
the quotas file. But we discovered there's a companion text file used by the
browser which we've now also loaded. So we can see all 1326 quotas (so far)
from the browser! But attempts to run quotacheck either from the browser or
CLI hang. kill quotacheck and you get /export locked. Yukk! There's a bug
on Sunsolve for this but no fix. We're using ufsdump/restore to load the
filesystem and it seems OK.

I believe that (with Sun's disapproval) it may be possible to reconfigure the
Multipac (12 x 4.2Gbytes) as (5 x 4.2) + (6 x 4.1) raid5 md's + 1 hotspare.
Anyone done this? We're novices at DiscSuite I'm afraid. This would make the
filestore more managable, I think.

We tried to change hostname/IP#, and it seemed to be OK. We found some old
names and IP#'s in /etc/opt files which we changed and all seemed OK, but
Backup has taken offence. Sun's solution is a reinstall, and (to quote)...
"it should be possible to retain the /export filesystem". Anyone done this?

Any kind of help and reassurance will be welcome.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:03 CDT