Date: Sun, 16 Sep 2001 19:49:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Emmerton <matt@gsicomp.on.ca> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <3BA564AF.BF642E23@mindspring.com> References: <3BA4B507.CC70ECD4@nipsi.de> <20010916140843.A21982@xor.obsecurity.org> <3BA52C79.E1E247F5@mindspring.com> <3BA5419F.BF0C3E70@nipsi.de> <3BA555D8.D2C53387@mindspring.com> <004001c13f1c$bbcc3100$1200a8c0@gsicomp.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Emmerton wrote: > > My bigest problem with it right now is license, since a GPL > > means that FreeBSD could not use it as a boot FS, which makes > > the code useless to me. > > I can see how FreeBSD would not ship GFS support in the GENERIC kernel > (which is GPL-clean), but I don't see why the choice of licence would > prevent anyone from using it as a boot FS. I can not install a precompiled kernel that can boot GFS. I can not boot an emergency boot floppy which is capable of mounting and repairing a GFS on a corrupt hard disk. I can not distribute a product which relies upon GFS as the boot file system, since in doing that, I would have to distribute an illegal binary. Since I have generally been working on FreeBSD based embedded systems for the last four years of my career, and could not use GFS under the current license in this context, it makes doing the work rather unintersting to me. It also makes my employers uninterested in funding my coding time on such a project. > This is of great importance to me, since I'm working on porting > JFS over to FreeBSD, which is GPL'ed code. Not being able to > have a root device which is journaled significantly reduces the > appear of having a journaled filesystem available. Yes. I contacted the OS/2 JFS people within IBM while I was an IBM employee for a little over a year, following IBMs acquisition of Whistle Communications. They were uninterested in releasing the code under another license, meaning they were willing to shoot one of their divisions in the foot in order to achieve their own political and marketing goals. Also, realize that Journaling has the same drawbacks in the face of a hardware failure as does any FS, and that software can not tell the difference between a loss of power, a kernel panic, or a hardware failure, without specially designed equipment. So if you come back up after a failure, you have to do the full check anyway, for safety's sake. So the utility of journalling is primarily in the fast boot after a normal shutdown, or an abnormal shutdown where the cause of the shutdown is known to the kernel prior to the mount. This is fixable... follow along: Unfortunately, PCs do not have a standard "transient OS use only" area (one that is not sensitive to which OS is using it) or even an "OS use only" area (which would throw fits on a dual boot system, but would at least allow it to work single OS) in the CMOS layout/BIOS interface to opaque CMOS location. This needs to be dealt with via a BIOS extension, I believe, and until it is, we're going to have to treat any failure as if it were a panic as a result of a corrupt disk buffer, from either a driver, controller, or physical disk failure. If we are taking votes, I would sugest using a structure like: struct { u_int_8 OS_type; /* which OS*/ u_int_8 count; /* size, including prefix*/ u_int_8 data[1]; /* actually bigger*/ }; And impose a limit in the BIOS interface on "count" that prohibits any single OS from taking all of it just to screw with other OS vendors ability to use the machine (not mentioning any likely names here, just precluding the problem). I would further suggest: 1) The count of available bytes comes from the BIOS interface. 2) vendors be required to have at least two OSs worth of maximum count size of storage (i.e.: the limit is count/2). 3) Records fill from the end, back. This also keeps a vendor from writing two or more records worth, as they will overwrite their own data, but more importantly, it lets the BIOS vendor keep a "free reserve", and use up bytes, as needed, shortening the maximum, but then letting each OS keep operating over BIOS upgrades (in this case, being the first OS means having the last record, which is better). 4) OS_type be the same as the DOS partition type for the OS, so a single OS is not permitted to use two areas, and thus screw with other OS vendors ability to use the machine (angain, not mentioning likely names here). 5) Give me credit for the idea somewhere, in the bowels of their documentation. 8-). FreeBSD could then add a subsystem parameter to the panic() routine (it should do this anyway!), so that it could decide what to write to its CMOS area so that on reboot it could make some good assumptions... this also implies the ability to make it assume "worst case: corrupt CMOS" from a boot prompt, so we don't get stuck. -- 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?3BA564AF.BF642E23>