From owner-cvs-src@FreeBSD.ORG Sat Apr 22 13:04:35 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8083016A401; Sat, 22 Apr 2006 13:04:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24FE543D49; Sat, 22 Apr 2006 13:04:35 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A280246C7A; Sat, 22 Apr 2006 09:04:34 -0400 (EDT) Date: Sat, 22 Apr 2006 14:04:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tom Rhodes In-Reply-To: <20060422085143.734e2f24.trhodes@FreeBSD.org> Message-ID: <20060422135926.K56433@fledge.watson.org> References: <200604210714.k3L7EQhD046878@repoman.freebsd.org> <20060421161321.J44089@fledge.watson.org> <20060421212322.2f5b3fa8.trhodes@FreeBSD.org> <1A949C80-E65D-4349-8028-8B0EB1A91D27@FreeBSD.org> <20060422001635.247a8b88.trhodes@FreeBSD.org> <20060422133933.A56433@fledge.watson.org> <20060422085143.734e2f24.trhodes@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, jhb@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_vfsops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 13:04:35 -0000 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