From owner-freebsd-questions Fri Jun 21 09:58:46 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23936 for questions-outgoing; Fri, 21 Jun 1996 09:58:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA23931 for ; Fri, 21 Jun 1996 09:58:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA18503; Fri, 21 Jun 1996 09:55:44 -0700 From: Terry Lambert Message-Id: <199606211655.JAA18503@phaeton.artisoft.com> Subject: Re: Transferring drive from Solaris 2.4 to FreeBSD To: ptroot@uswest.com (Paul T. Root) Date: Fri, 21 Jun 1996 09:55:43 -0700 (MST) Cc: questions@freebsd.org In-Reply-To: <199606211326.IAA02436@astro.acs.uswest.com> from "Paul T. Root" at Jun 21, 96 08:26:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have a couple of SyQuest EZ135 drives, one on my Sparc Tadpole (Solaris 2.4) > at work and one on my 486 FreeBSD box at home. The drive works great on > both boxes, and the obvious next step is to have both machines use the > same disk so I can move 100 Meg at a time without using the 28.8 line. > > Is this possible? I configured the disk on FreeBSD to not interoperate > with other OSs on the PC. Which I read to mean that It ignores fdisk > stuff and just writes to the whole disk. But that still wouldn't mount > on my Sparc. > > Anybody have an idea on this? This is an interesting issue that I can't do anything about for a while. My knee-jerk response is that we will want to recognize the Sun disklabel format using logical to physical device translation (label-to-device/offset/range vnode conversion)... which needs DEVFS. >From there, it's a pretty trivial (but not yet implemented) hack to to make the BSD FFS handle Sun volumes, specifically default value areas for the "spare" fields for ACL management, to make that all happy. Part of it is a byte-order issue, part of it is a bit definition issue. I'm somewhat antsy about the DEVFS as it currently exists because of the way root mounts are handled; I'd like to preferentially handle the DEVFS as an intrinsic mount relative to the root, and then union mount the real root on top of that. This allows support of the symlink constructs that everyone is whining about, without munging the DEVFS itself. It also deals with a couple of chroot issues that are unresolved with DEVFS, at this time. One potential workaround, for the near term, would be to deal with the volumes as DOSFS volumes. This leaves a bad taste in your mounth, but it *will* work as a workaround, for now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.