Date: Mon, 17 Sep 2001 02:51:07 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Christoph Hellwig <hch@ns.caldera.de> Cc: Dennis Berger <Dennis.Berger@nipsi.de>, freebsd-fs@FreeBSD.ORG, opengfs-devel@lists.sourceforge.net Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <3BA5C78B.FE14882@mindspring.com> References: <3BA4B507.CC70ECD4@nipsi.de> <20010916140843.A21982@xor.obsecurity.org> <3BA52C79.E1E247F5@mindspring.com> <3BA5419F.BF0C3E70@nipsi.de> <3BA555D8.D2C53387@mindspring.com> <20010917084023.A13990@caldera.de> <3BA5AF53.EE87658F@mindspring.com> <2 <3BA5BDBC.107DC520@mindspring.com> <20010917113627.A28298@caldera.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Christoph Hellwig wrote: > > This disagrees with a discussion I had off list, as to the use > > and availableility of DLOCK, and the firmness of the SCSI III > > standard. The GFS people are using Matt Jacob's fiberchannel > > driver, and a network based distributed lock manager. > > DLOCK was GFS 3.x. GFS 4.x and OpenGFS use dmep. I think you are misunderstanding me. There is a SCSI III primitive in the drafts that permits multiple masters to range lock disk ranges to a a particular host. By doing this, it permits multiple writers, by guarantees that each host will not overlap a write. It also causes a writeback invalidation for other masters, in order to effect a distributed cache coherency protocol, without additiona daemons or hardware. > > > > preclude using it as a boot FS, or shipping a CDROM which would > > > > install to it as the root FS type, by way of user selection > > > > (preferred) or by default (annoying to commercial users). At least > > > > I can actually use the code... > > > > > > The first yes, the second not. > > > > Tell me how I can distribute a binary, where it is impossible for > > all the code to be under GPL because some of the code is under > > another license, yet statically link it with GPL'ed code? > > I never said that you can redistribute the binary. Can you explain "The first yes, the second not"? It's a bit cryptic, then... [ ... ] > But I really hate this stupid license discussions, especially on > technical lists. The problem is that you have proposed a technical solution which is politically impossible. You have to expect political reasons why it is impossible to result from the suggestion. Basically, you are calling for volunteers to work on something they won't be able to use, when it's done. > You can link it withput problem - as long as you don't redistribute the > linked product. I might as well use XFS, then, which is at least being ported to FreeBSD... > > If someone would write a fiberchannle driver, and tell me where I > > can buy cheap hardware, I could probably write a GFS-like FS from > > scratch; but it's not something I'm interested in taking on, if it > > means that there's nothing to run it on but local disks, when I get > > there (ugh!). > > You can use OpenGFS without dmep-capable hardware as well, there's > still the IP option. That's much less useful. I'd work on an FS that could do what GFS or XFS could do, without the encumberanbces, and assuming that it was all FS work, and not driver work for hardware I don't have yet. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA5C78B.FE14882>