In regard to: [Networker] Big endian versus little endian?, George Sinclair...:
>There's been a lot of talk over this business of moving from one OS to
>another; e.g. Solaris to Linux. I've heard some different things about
>this, most notably the index problem. Some say it's worked, others have
>said it won't and that you basically have to start over with new
>indexes. Thought some others suggested just starting completely from
>scratch but keep the old server around for any restores from tapes that
>were written to when the old server was in use. Maybe that was with
>Microsoft. Anyway, was there any final consensus on this issue?
I think the conscensus is that you can't migrate between platforms (UNIX
or Linux to Windows, or vice versa), but migration between different UNIX
platforms *should* work. I've seen people say on this list that Legato
has told them that migrating from one UNIX (typically I've seen HP-UX
mentioned) to some other (typically Solaris or Linux) will not work, but
I'm frankly skeptical of that.
>Let's say I want to move the primary server from Solaris to Linux. I'm
>not sure which is Big endian or which is little endian. Maybe they're
>both the same, but I'm thinking they're not.
Solaris on SPARC runs in big endian mode, Linux on Intel is little-endian.
Note that many RISC chips are multi-endian, which means that if your OS
supports it there's no reason why you couldn't run in little endian mode
even if the default is big endian. I'm not aware of any commercial UNIX
platform that actually supports that, though.
> Several people have said
>that this endian difference will create problems when you try to read
>the indexes on the new server, although I would assume that since
>they're ordinary files (we're running 6.1.1 so I know they are with that
>release), physically getting them there should not be a problem.
As I recall, once you're at 6.x, the client indexes are endian-neutral,
essentially meaning that they can be read correctly no matter what
endianess the host platform has. The media database is (again, as I
recall) *not* endian-neutral, so it is tied to a particular byte-order.
What I know less about is how tied to a particular data "size" the indexes
are. Tru64 on Alpha and Linux on Intel are both little-endian platforms,
but certain data sizes since Tru64 is LP64 and i*86-*-linux* is ILP32.
I don't know what kind of a difference that would make, but I would assume
it makes some.
>Guess
>the bytes are read in a different order, though, or some such thing.
>Can't recall my Jonathan Swift details on that, but I do recall the main
>problem spoken of was the transferring of the client indexes from one
>endian to a different endian. Was this in fact the real only concern
>when moving from one platform to another?
No, I think the primary problem is the media database, not the client
indexes.
The thing is, even when you're moving from a big-endian platform to
a little-endian, there are procedures that you can go through to
do all necessary conversion. As long as you perform those procedures,
the conversion should be no problem.
I know this, because I've actually done it. We migrated from Tru64
to Linux as our backup server, and the migration was easy. You basically
do the same thing you would do in a (networker server) disaster recovery
situation. Install the server software (in the exact same spot, i.e.
/nsr needs to point to the same spot it did on your old server) on your
new host, load the media database from tape using your most recent
bootstrap, and then after putting your recovered config in place, fix
it up (if needed, like if your jukebox or tape path names changed when
you moved to the new platform), and then import your client indexes.
A `uasm' on your old server platform, sent over an rsh/ssh connection to
a `uasm' on your new server platform should be enough convert your client
indexes, if any conversion is truly needed. You could also just build
your indexes for each client using scanner, but that's kind of icky.
That procedure worked perfectly for me when we migrated our server platform.
I'm not sure why some people have not been able to migrate using the
DR procedure, but apparently it doesn't work for some.
Tim
--
Tim Mooney mooney AT dogbert.cc.ndsu.NoDak DOT edu
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
