Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Feb 2003 03:15:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Feb 2003 03:15:39 -0500 Received: from daimi.au.dk ([130.225.16.1]:27052 "EHLO daimi.au.dk") by vger.kernel.org with ESMTP id ; Thu, 27 Feb 2003 03:15:36 -0500 Message-ID: <3E5DCB89.9086582F@daimi.au.dk> Date: Thu, 27 Feb 2003 09:25:45 +0100 From: Kasper Dupont Organization: daimi.au.dk X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-19.7.xsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: Miles Bader CC: DervishD , Linux-kernel Subject: Re: About /etc/mtab and /proc/mounts References: <20030219112111.GD130@DervishD> <3E5C8682.F5929A04@daimi.au.dk> <3E5DB2CA.32539D41@daimi.au.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2941 Lines: 75 Miles Bader wrote: > > Kasper Dupont writes: > > > /var is clearly the right place for this; > > > > Is it? > > Yes. On some systems, /var and /tmp are the _only_ read-write filesystems. OK, but then on such a system with my approach it would be possible to make /mtab.d a symlink pointing to somewhere under /var. > > > > if /var isn't mounted initially, I'd suggest that mount should > > > simply not update any file at that point, and the init-script that > > > mounts /var can be responsible from propagating information from > > > /proc/mounts to /var/whatever. > > > > Would you fsck /var while it is mounted? > > No, of course not; that's why I suggest it's up to the init scripts to > make sure that /proc/mounts gets propagated to /var/whatever. They > usually will know enough about what's going on to take care of any > special cases and add any extra info that's relevant. But AFAIK fsck uses mtab. > > If a program such as `mount' wants to use mtab and finds that it's not > present (possibly because /var isn't mounted), it should either use > /proc/mounts instead, or just ignore it. If mtab does not exist mount will attempt to create a new one with only the root listed. > > > I think part of the problem is that /var is used for both files > > we want to keep across reboot, and files we do not want to keep > > across reboot. > > [/var/run is for `non-persistant' files] But that doesn't solve the problem with ordering. If we don't want to change a lot of userspace utilities and the order in which things are done during boot, we need /var/run mounted earlier than /var. And /var/run is not the only directory with files we do not want to keep across boot. There are some in /var/lock too, and AFAIR a few other locations. > > > There are cases where it is undesirable to have mtab in /var, > > but if mount expect to find mtab somewhere under /var, we can't > > even use a symlink to get it out of there, because /var needs > > to be mounted before the symlink can be followed. > > It will simply appear to mount as if the file isn't present, in which > case it should gracefully stop trying to use it [see above]. > > It seems like the attempt here is to somehow make everything just work > magically _without_ modifying any tools that use mtab -- and I think > that just isn't doable in every situation. Maybe not, but I certainly don't want to change every program that reads mtab. If we can limit the changes to those tools that needs to write mtab, it might be feasible. -- Kasper Dupont -- der bruger for meget tid p? usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/