From owner-freebsd-current@FreeBSD.ORG Mon Jun 28 18:26:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E17616A4CE for ; Mon, 28 Jun 2004 18:26:48 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id C634F43D2D for ; Mon, 28 Jun 2004 18:26:47 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from hawkwind.Chelsea-Ct.Org (pool-151-199-92-118.roa.east.verizon.net [151.199.92.118]) by gromit.dlib.vt.edu (8.12.11/8.12.11) with ESMTP id i5SIQYaN019253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jun 2004 14:26:46 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from [192.168.1.25] (zappa [192.168.1.25])i5SIQMJO005848; Mon, 28 Jun 2004 14:26:22 -0400 (EDT) From: Paul Mather To: freebsd-current@freebsd.org In-Reply-To: <20040628140736.ADE7516A4CF@hub.freebsd.org> References: <20040628140736.ADE7516A4CF@hub.freebsd.org> Content-Type: text/plain Message-Id: <1088447180.1942.55.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 28 Jun 2004 14:26:22 -0400 Content-Transfer-Encoding: 7bit cc: Carl Makin Subject: Re: HEADSUP: ibcs2 and svr4 compat headed for history X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2004 18:26:48 -0000 On Mon, 28 Jun 2004 11:10:53 +1000, Carl Makin 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@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