From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lutomirski Subject: Re: [rfc] new stat*fs-like syscall? Date: Thu, 24 Jun 2010 10:37:31 -0400 Message-ID: References: <20100624131455.GA10441@laptop> <4C2366F7.5010200@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: npiggin@suse.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, drepper@redhat.com, torvalds@linux-foundation.org To: Miklos Szeredi Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jun 24, 2010 at 10:18 AM, Miklos Szeredi wr= ote: > On Thu, 24 Jun 2010, Andy Lutomirski wrote: >> Something like fsid but actually specified to uniquely identify a >> superblock. =A0(Currently, fsid seems to be set by the filesystem, a= nd >> nothing in particular ensures that two different filesystems couldn'= t >> have collisions.) =A0We could guarantee (or have a flag guaranteeing= ) that >> (fsid, st_inode) actually uniquely identifies an inode. >> >> Similarly, something like fsid that uniquely identifies the vfsmount >> could be useful, although I don't know how easy that would be to pro= vide >> for fstat?fs. >> >> If we could expose the complete set of filesystem mount options so t= hat >> mount(1) didn't have to look at /proc/self/mounts or /etc/mtab, then >> playing with chroots would be that much easier. >> >> Should we expose superblock and vfsmount options separately? =A0We h= ave >> read-only bind mounts now, but the way they work is rather inscrutab= le, >> and if stat?fs could say "superblock is read-write but vfsmount is >> readonly" then people might be able to make more sense of what's goi= ng on. > > You'll find all of those things in /proc/self/mountinfo. Wasn't the point that /proc/self/mounts (and presumably /proc/self/mountinfo) isn't scalable and we wanted a syscall to query it efficiently (and racelessly)? --Andy