From owner-freebsd-questions Sun Feb 5 12:39:43 1995 Return-Path: questions-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA02658 for questions-outgoing; Sun, 5 Feb 1995 12:39:43 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA02649 for ; Sun, 5 Feb 1995 12:39:40 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA02973; Sun, 5 Feb 95 13:33:42 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502052033.AA02973@cs.weber.edu> Subject: Re: Disk Mirrors To: rjs@clark.net (Ron Steele) Date: Sun, 5 Feb 95 13:33:41 MST Cc: freebsd-questions@freefall.cdrom.com In-Reply-To: from "Ron Steele" at Feb 3, 95 09:07:08 pm X-Mailer: ELM [version 2.4dev PL52] Sender: questions-owner@FreeBSD.org Precedence: bulk > So, I would be interested in developing some sort of mirroring/logical > volume capability for FreeBSD. I feel that this would lend a lot of credit > to FreeBSD as a "commercial" product, and perhaps make it a more > acceptable replacement for commercial Unix systems to people > that may be reluctant to use a freeware product. > > I am an experienced C/Unix person, but have never gotten my feet wet > in the kernel, so I would need some mentoring. Still I think I could > pull this off with a little help. > > If anyone else is interested in pursuing this please email me. Some > words of encouragement from an experienced file system person would be > especially welcome. A "correct" implementation would require file system changes to insure cross volume staggered synchronization and two drive recovery using fsck to pick "more correct" information for best recovery. A quick and dirty implementation would require the minimum work, that of abstracting geometry and offset information for non-identical drives to provide the lessor of two sector extents in the case that the disks are not identical. It would also require "perfect media" -- or pseudo-perfect. For other than SCSI, this means getting BAD144 working reliably. If you didn't do this, indexing would be a nightmare, as would identically selecting inodes and disk blocks for use without some kind of master/slave relationship between the drives (symmetry is the key). This probaly means VM changes for dirty page handling. I would suggest checking out the papers on Zebra and other high availability work in the past Proceedings of Usenix (ftp.sage.usenix.org). Not that I recommend Zebra. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.