Setting up Netware 3.12 - Netware

This is a discussion on Setting up Netware 3.12 - Netware ; Replacing a Netware 3.12 server with a new one to be installed with the same version of Netware. What files I can copy from the old server to the new one without re-setting up all the user and system profile. ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Setting up Netware 3.12

  1. Setting up Netware 3.12

    Replacing a Netware 3.12 server with a new one to be installed with the same
    version of Netware.

    What files I can copy from the old server to the new one without re-setting
    up all the user and system profile.

    Thanks for any input.

    Evers




  2. Re: Setting up Netware 3.12

    In article , Evers
    writes
    >Replacing a Netware 3.12 server with a new one to be installed with the same
    >version of Netware.
    >
    >What files I can copy from the old server to the new one without re-setting
    >up all the user and system profile.
    >
    >Thanks for any input.


    Use the migrate utility. Install the new server with a new name, migrate
    all the data and users from the old server to the new one. Down the old
    server, rename the new server to the old name. Migrate doesn't (or
    didn't) bring the passwords across, but if you do a bindfix twice on the
    old server and copy the backup bindery files across onto the new server
    and do a bindrest, all the accounts should come back.

    HTH
    --
    Nick

  3. Re: Setting up Netware 3.12

    Johnny B Good wrote:

    > It just seems very strange that despite the three orders of magnitude
    > improvement in processing power and one and a half orders of magnitude
    > in memory capacity and two orders of magnitude in drive performance that
    > I'm barely seeing much more than a doubling of sustained data transfer
    > rate for writing to disk.
    >
    > I'm sure I can't be the only one that's observed this 'post upgrade'
    > lack of performance boost in a 3.12 server. :-(


    It has long been said that Netware 3.12 is a very efficient file-sharing
    system, and would run very well on a 386, even into Pentium days.
    Increasing processing power makes very little difference, as not much is
    needed; increasing memory and disc speed are about the only things that
    pay off. The memory merely serves to cache disc directories; large discs
    require more memory anyway.

    I don't think that drive performance has increased by two orders of
    magnitude (x100) since 386 days; where in 1988 you had a 3600 rpm disc
    with a mean access time of 20ms (maybe faster with high-end SCSI
    drives?), you now have anything from 5400 to 15000 rpm & 5ms.

    If you're comparing with a modern IDE disc, that'll be 7200rpm: there's
    your factor of two.

    Best wishes,
    --
    Michael Salem

  4. Re: Setting up Netware 3.12

    On Fri, 18 Jul 2003 23:28:44 +0100, Johnny B Good
    wrote:

    >The message
    >from Nick contains these words:
    >
    > I just simply temporarily add the new drive, make a small (60 odd MB
    >dos boot partition) and xcopy the dos stuff over followed by fat32
    >partition of the remaining space to help the novel partition utility
    >discover there's more to a disk than 8GB :-( The disk volume intended
    >to become SYS (If I'm replacing that drive) is set to 1GB and given a
    >name like SYSTEMn (where n is a digit to avoid naming conflicts). Having
    >created the required disk volumes I simply login from a win9x
    >client/workstation and copy everything over from the old to the new
    >followed by removal of old drive and a bit of disk volume name juggling
    >to finish the upgrade, oh yeah followed by the bindrest command :-)


    Why not just keep a separate drive for the DOS boot partition. Makes
    life a lot easier when swapping around.

    > Can anyone explain to me why, despite upgrading from a 386SX MoBo with
    >16MB ram and a 600MB ESDI drive and 10Mbps cheapernet to a K6/2/300
    >(that's a 500MHz chip *underclocked*, BTW) with 512MB ram and 80 and
    >120GB drives with 100Mbps ethernet, that the write to disk performance
    >has only improved by a factor of TWO (that's after the disk cache has
    >filled < just under 1MB/s transfer rates>) despite my using a promise
    >ATA100 controller and the latest drivers?
    >

    What are your new drives, SCSI ESDI or IDE. ESDI were pretty
    efficient in in Novell server. SCSI would be your best option now.
    But you probably are not pushing the system hard enough to see the
    difference. Put 20 users on your old system and put 20 users on your
    new system and see what happens.


    --
    TonyL

  5. Re: Setting up Netware 3.12

    The message
    from Michael Salem contains these words:

    -----------snip----------

    > I don't think that drive performance has increased by two orders of
    > magnitude (x100) since 386 days; where in 1988 you had a 3600 rpm disc
    > with a mean access time of 20ms (maybe faster with high-end SCSI
    > drives?), you now have anything from 5400 to 15000 rpm & 5ms.


    > If you're comparing with a modern IDE disc, that'll be 7200rpm: there's
    > your factor of two.


    I wasn't refering to access times, I was refering to sustainable data
    throughput. This *has* improved by about two orders of magnitude in that
    the origional 600MB ESDI drive could only manage about 450KB/s whereas
    today's 80 and 120GB drives can now manage something like 45MB/s
    transfer rates. Admittedly, this performance drops off to about half of
    this on the innermost cylinders.

    It's worth bearing in mind that, for a given number of platters and
    rotation speed, each time the areal density is doubled, the data
    transfer speed improves by some 41%. Since modern 1 inch high drives
    have anything from 1 to 3 disk platters (2 to 6 heads) virtually all of
    the capacity increases arise from improvements in areal density.

    There was, very early on in the development of IDE drives (with their
    self contained controllers), a significant boost of capacity simply due
    to the use of more sophisticated RLL encoding techniques. That alone
    accounts for a doubling of data transfer rates B4 we even consider the
    improvements due to magnetic coating technology and increased rotational
    speeds.

    Also, another consideration is the more efficient use of that areal
    density permitted by the self contained controller in that the outermost
    cylinders can store twice as many sectors per track as on the innermost
    cylinders and thus double up yet again the data transfer rates (at least
    for the bulk of the drive's capacity).

    What I'm testing is data throughput for large files (say several
    hundred MB to 3 or 4 GB in size) and the use of a stopwatch to either
    time a large file transfer from the workstation or else time the
    throughput as shown when using the server's monitor function of the
    LAN's bytes transfered statistic which updates once a second.

    If I make such measurements B4 the fileserver's buffer fills, I get a
    figure around the 4MB/s mark (about the same as for reads). Since, in
    the early days of 10Mbps cheapernet and for reads at least, I could see
    transfer rates just over the 900KB/s second mark when using good quality
    ethernet adapters.

    I'm just amazed that I don't see a tenfold improvement with 100Mbps
    full duplex NICs. In fact, the best I've ever seen was around the 7MB/s
    when testing with two win9x machines back to back via a cross-over
    cable. In both cases, BTW, I'm using IPX/SPX protocols. I don't believe
    in using an internet protocol for local file sharing when a perfectly
    good (and secure!) non-internet protocol serves just as well! I suspect
    the protocol (and the MTU? size) is not as optimised for 100Mbps as it
    was for 10Mbps but I'd have thought the full duplex mode would mitigate
    this effect.

    --
    Regards, John.

    To reply directly, please remove "buttplug" .Mail via the
    "Reply Direct" button and Spam-bots will be rejected.


+ Reply to Thread