cvs commit: src/sys/ufs/ffs ffs_vfsops.c

[Tom Rhodes]

On Fri, 21 Apr 2006 21:33:06 -0400
John Baldwin <jhb at FreeBSD.org> wrote:

> 
> On Apr 21, 2006, at 9:23 PM, Tom Rhodes wrote:
> 
> > On Fri, 21 Apr 2006 16:15:15 +0100 (BST)
> > Robert Watson <rwatson at FreeBSD.org> wrote:
> >
> >>
> >> On Fri, 21 Apr 2006, Tom Rhodes wrote:
> >>
> >>> trhodes     2006-04-21 07:14:25 UTC
> >>>
> >>>  FreeBSD src repository
> >>>
> >>>  Modified files:
> >>>    sys/ufs/ffs          ffs_vfsops.c
> >>>  Log:
> >>>  Remove what I believe are two useless ifdefs.  If a user or  
> >>> administrator
> >>>  enables multilabel, or any option for that matter, most likely  
> >>> they have
> >>>  a reason.  This will allow users to see that mulilabel is  
> >>> enabled via an
> >>>  issued "mount" command and remove an annoying warning - printed  
> >>> only when
> >>>  a MAC kernel is not installed - on boot up.
> >>
> >> This seems incorrect to me.  You have also removed the warnings  
> >> associated
> >> with trying to use multi-label and ACL-enabled file systems on  
> >> kernels not
> >> configured to support them, which can lead to highly undesirable  
> >> behavior,
> >> hence the warnings.  The mount point flags are intended to reflect  
> >> the current
> >> mode of operation, and setting the flags when the operational mode  
> >> isn't
> >> supported doesn't seem right.
> >>
> >
> > 4: With regards to number 2, I think the option should at least
> >    be spit out with all other options when using mount(8) to
> >    review file system information.
> 
> You might want to look at softupdates as a prior example.  If you  
> marked a
> filesystem with softupdates but didn't have softupdates compiled into  
> the
> kernel, mount didn't show softupdates as being enabled (IIRC).  I think
> mount should show you the actual features of the filesystem that are  
> actually
> working rather than implying that an optional feature is working when it
> actually isn't.  If you are depending on the labels for security  
> purposes, I
> think it is useful to know if you boot a kernel that is missing the  
> required
> support and potentially leaves your data unprotected.

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.

> 
> > 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

Yes.

> 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?


-- 
Tom Rhodes