cvs commit: src/sys/ufs/ffs ffs_vfsops.c
rwatson at FreeBSD.org
Sat Apr 22 12:45:37 UTC 2006
On Sat, 22 Apr 2006, Tom Rhodes wrote:
> Which is why I suggested that, similar to Linux, we make everything an
> option instead of either Warning before you build/install the new kernel or
> add the addition headache of turning it on later. Thus, I'm still of the
> opinion that one does not blindly add a newfs option during the install
> without understanding what's going on.
The problem you're diagnosing is booting a kernel that doesn't support
features requested by the administrator. When this happens, there are really
only two things you can do:
(1) Generate warnings and continue.
(2) Generate warnings and stop.
We opt for (1) because it makes recovery easier. Deleting the warnings helps
neither case. Booting an SELinux system without an SELinux kernel will fail
in many spectacular ways, but I'm not sure if they generate a warning
equivilent to the one you deleted.
BTW, turning on the multilabel flag in sysinstall is not an option offered by
the installer -- by setting it using sysinstall's "additional flags" field,
you're specifially doing something not part of the install path. The MAC
instructions I've provided always involve completing the normal install,
building MAC support, etc, not turning it on in sysinstall and expecting it to
work. The only instructions I've distributed that involve setting multilabel
in sysinstall relate to the SEBSD install ISOs, which explicitly support
flagging multilabel support during the install.
>>> I'll revert it if you feel strongly about it; however, I want it
>>> to be known what my opinion is. And I find the warnings
>>> extremely annoying and have answered at least one question as
>>> to why "mount don't show me correct output." Yes, real quote. :)
>> mount != tunefs. tunefs will tell you what options are enabled in the
>> filesystem, but I think mount should only tell you the options that are
>> actually in force.
> Once they're enabled does that not mean they are in force?
I'm not sure what you mean by "enabled" here. Flags only have an effect if
the kernel code to support them is compiled in. The way the code was before
you modified it, the flags could not be shown in mount if the kernel didn't
implement them -- i.e., if you type in "mount" and don't see ACLs, then they
are not implemented, and if you do see ACLs, then they are implemented. With
your change, they can now be set but not implemented. I.e., you can look at
mount, see "acls" set, but ACLs won't actually be in force, which I consider a
more confusing failure mode. If you mean, can they be enabled in tunefs but
not in force -- yes, if you are running a kernel that can't support them. In
which case, before your change, a warning was generated, but not now.
Robert N M Watson
More information about the cvs-all