Re: HEADSUP: ibcs2 and svr4 compat headed for history

On Mon, 28 Jun 2004 11:10:53 +1000, Carl Makin <carl_at_xena.IPAustralia.gov.au> wrote:

> On Sat, 2004-06-26 at 19:32, Poul-Henning Kamp wrote:
> 
> > The ibcs2 and svr4 compatibility code has outlived their useful lives,
> > mainly because their target platforms are practically extinct.
> > 
> > They will be eliminated from -current in the coming week, unless very
> > compelling reasons to the contrary are put on the table.
> 
> It will cause us a lot of grief unless we can find an alternative way to
> run IBM's Tivoli Storage Manager.  We currently use the SCO v2 client
> which has huge warts, but runs.

Are you using this under 5.x??  It doesn't run for me (not since my
first foray into 5.x with 5.1-RELEASE), and I have heard the same from
others.  Apparently, it still doesn't work.  Here is what I get with a
5.2-CURRENT kernel built yesterday:

zappa# ./dsmc
Abort
zappa# ktrace ./dsmc
Abort
zappa# kdump
  2161 ktrace   RET   ktrace 0
  2161 ktrace   CALL  execve(0xbfbfed8b,0xbfbfec94,0xbfbfec9c)
  2161 ktrace   NAMI  "./dsmc"
zappa# file ./dsmc
./dsmc: MS Windows COFF Intel 80386 object file
zappa# kldstat
Id Refs Address    Size     Name
 1   22 0xc0400000 328934   kernel
 2    1 0xc0729000 b8d0     snd_ds1.ko
 3    2 0xc0735000 204a4    snd_pcm.ko
 4    8 0xc0756000 12fc8    agp.ko
 5   14 0xc0769000 56fe4    acpi.ko
 6    1 0xc1448000 2f000    nfsclient.ko
 7    1 0xc14b0000 2000     green_saver.ko
 8    1 0xc14d1000 19000    linux.ko
 9    2 0xc1ea2000 b000     ibcs2.ko
10    1 0xc1eaf000 3000     ibcs2_coff.ko
zappa#

I reported this a while ago.  The consensus reply was that iBCS2
emulation was essentially unmaintained and had fallen prey to bitrot due
to the kernel changing elsewhere underneath it.  The suggestion from
Tivoli users was to bite the bullet and switch to the Linux client. 
(The SCO V2 client still runs for me under 4.10-STABLE.)

Dan Nelson did do a little investigation into iBCS2 emulation in 5.2 and
posited that a memory mapping issue may be to blame.  (See
http://lists.freebsd.org/pipermail/freebsd-emulation/2004-March/000377.html)

> The linux client trips over the whole filesystem overlay thing badly and
> I'm not sure disabling that to run just the TSM client is a good idea.
> (Plus I hate the idea of maintaining custom kernel patches.)

I agree the filesystem overlay is a pain, but you can work around it
with a little effort.  My current solution (on a 5.2.1-RELEASE-p8
system) is to use the FreeBSD snapshot functionality coordinated via
PRESCHEDULECMD and POSTSCHEDULECMD options in my dsm.sys file.  The
PRESCHEDULECMD runs a script that makes and mounts under /backup
snapshots of the filesystems I want to back up, and POSTSCHEDULECMD
unmounts and removes the snapshots. (One nice side-effect of this is
that objects are guaranteed not to rebound during backup.)  I had been
using nullfs mounts under /backup previously, but this is a little less
messy, IMHO.

The disadvantage of the snapshot approach is that you can't restore
in-place.  So, restoring /backup/usr/... would involve restoring it to,
e.g., /usr/backup/... and then moving it to /usr/...  (But I'm not sure
in-place restores were that safe under rw nullfs mounts, given the dire
warnings in the BUGS section of mount_nullfs.:)

Of course, all this is only required if you are backing up something
that is actually shadowed.  If you have a /home filesystem and are only
backing up that, none of these filesystem gymnastics are required. 
(Just make sure you have /home in your /compat/linux/etc/mtab so that
the TSM client can see it.)

One advantage of using the Linux TSM client over the SCO V2 is that my
TSM administrator no longer frets about me using an unsupported
client... :-)

(Plus, you get other goodies like being able to back up symlinks as
symlinks, etc., which I don't recall being supported under the old SCO
client.)

Cheers,

Paul.
-- 
e-mail: paul_at_gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa