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

[Robert Watson]

On Sat, 22 Apr 2006, Tom Rhodes wrote:

>> 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
>
> Heh, exactly why I wanted to remove it.  :)
>
> Someone would need a reason to do it this way, I was hoping in this case 
> that someone would have a clue.
>
> It's reverted in any case.  ;)

Thanks.  BTW, your concerns are not unwarranted -- the problem here is how to 
deal with optional features that don't like being optional, and there's not 
really a good way.  The choice is really between having the system refuse to 
run at all under those circumstances, and allowing it to run enough to allow 
the administrator to recover.  Neither works well.  The trick, I think, is to 
be as consistent as possible in presenting the results.  The mount reporting 
pieces are a bit confusing, as different file systems are configured in quite 
different ways, etc.

What we'll need to do is be careful to document the difference between 
requests and status, as mount accepts requests, but reports status.  That and 
provide a FAQ/debugging guide, with things like "If I set multilabel with 
tunefs, but it doesn't appear in mount, what's going on?".  The answer is: 
check to see if it was properly set in the superblock using tunefs, and check 
dmesg for warnings relating to MAC.  If it's not set in the superblock, there 
was either user error or an error at set time; if it is set, then most likely 
MAC is not compiled in.  Similar comments for ACL, but this will turn up less 
since we compile UFS_ACL into GENERIC, so people are less likely to run into 
it.  One of the discussion topics for the dev summit will be what needs to 
happen to MAC to get it compiled into GENERIC, but we have a ways to go on 
that one.

Robert N M Watson