From owner-cvs-all@FreeBSD.ORG Fri Mar 16 11:20:22 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24E6716A404; Fri, 16 Mar 2007 11:20:22 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id B691313C45A; Fri, 16 Mar 2007 11:20:21 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 470505DFE16; Fri, 16 Mar 2007 22:20:02 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id D387C2740C; Fri, 16 Mar 2007 22:20:00 +1100 (EST) Date: Fri, 16 Mar 2007 22:19:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek In-Reply-To: <20070316032606.GC3229@garage.freebsd.pl> Message-ID: <20070316221953.I34698@besplex.bde.org> References: <200703160313.l2G3DTHP048236@repoman.freebsd.org> <20070316032606.GC3229@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jmallett@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libufs type.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 11:20:22 -0000 On Fri, 16 Mar 2007, Pawel Jakub Dawidek wrote: > On Fri, Mar 16, 2007 at 03:13:29AM +0000, Pawel Jakub Dawidek wrote: >> pjd 2007-03-16 03:13:29 UTC >> >> FreeBSD src repository >> >> Modified files: >> lib/libufs type.c >> Log: >> The ufs_disk_fillout(3) can take special device name (with or without /dev/ >> prefix) as an argument and mount point path. At the end it has to find >> device name file system is stored on, which means when mount point path is >> given, it tries to look into /etc/fstab and find special device >> corresponding to the given mount point. This is not perfect, because it >> doesn't handle the case when file system is mounted by hand and mount point >> is given as an argument. >> >> I found this problem while trying to use snapinfo(8), which passes mount >> ... > > In my opinion, when mount point is given, it should always just use > statfs(2) and don't touch /etc/fstab, but I didn't want to change the > current behaviour. Juli, do you have an opinion about this? It has to look in fstab to handle the case where the file system is not mounted. Perhaps where it looks should be controlled by its caller. Utilities like fsck_ffs and tunefs start with a special file name and only care if the file system is mounted. Then this interfaces is not very relevant, and looking in fstab makes it less relevant. fsck_ffs doesn't use ufs_disk_fillout. It searches all mount points to determine if the special file is mounted. tunefs uses ufs_disk_fillout() to help get this wrong, probably in much the same way as snapinfo() (e.g., the cases where the file system is mounted at a point not in fstab or at a point different from in fstab can't work without a search for the mountpoint). Your change doesn't add searching for the mountpoint (starting from a special file name), so it doesn't help tunefs. ufs_disk_fillout() remains almost irrelevant to tunefs. (tunefs is using it for its side effect of mapping from the special file name (if tunefs's arg is a special file name and not a mountpoint name to begin with) to a mountpoint name. Then mountedness can easily be determined by statfs() and/or stat() on the mountpoint name followed by strcmp() of names and/or comparison of device numbers, provided the mountpoint name is correct if the special file is mounted. The actual ufs disk info is not used.) Bruce