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>