Re: [PATCH 2/8] VFS: per inode statfs (core)

[Jan Hudec <bulb@ucw.cz>]

On Wed, Oct 26, 2005 at 22:10:09 +0200, Miklos Szeredi wrote:
> > > > > > > This patch adds a statfs method to inode operations.  This is invoked
> > > > > > > whenever the dentry is available (not called from sys_ustat()) and the
> > > > > > > filesystem implements this method.  Otherwise the normal
> > > > > > > s_op->statfs() will be called.
> > > > > > > 
> > > > > > > This change is backward compatible, but calls to vfs_statfs() should
> > > > > > > be changed to vfs_dentry_statfs() whenever possible.
> > > > > > 
> > > > > > What the fuck for?  statfs() returns data that by definition should
> > > > > > not depend on inode within a filesystem.
> > > > > 
> > > > > Exactly.  But it's specified nowhere that there has to be a one-one
> > > > > mapping between remote filesystem - local filesystem.
> > > > 
> > > > Unfortunately making statfs alone aware of them does not help. Most useful
> > > > tools that use statfs go to /proc/mouts, read all the entries and invoke
> > > > statfs for each path. So if for some non-root path different values are
> > > > returned, these tools won't see them anyway. So try to think about how to
> > > > provide the info about subfilesystems first.
> > > 
> > > 'df .': tried it and it did not do what was expected, but that can
> > > definitely be fixed
> > 
> > It *did* what was expected -- walked back up to the mountpoint and called
> > statfs there.
> 
> Yes, but I didn't expect that it would do that.  Why?  Because I asked
> it for free space in the current directory and not at the mountpoint.
> 
> Since it's not _expecting_ subfilesystems to exist, it's
> understandable that it did not perform well.
> 
> > And it cannot be fixed (without loss of functionality) unless
> > you somehow tell it where the boundary of the subfilesystem lies.
> 
> Of course it can be fixed.  Just always let it do
> statfs(path_supplied_by_user).  If there are no subfses the results
> will be the same.  If there _are_ subfses the results will be more
> meaningful, not less.

Not _without__loss__of__functionality__. Part of the functionality is
looking up the mount-point and other info about the filesystem, which is
no longer correct when subfilesystems are exposed.

> [...]
> > > None of the above examples need (and use) /etc/mtab or /proc/mounts.
> > > 
> > > Just because the info is not available about the placement of the
> > > subfilesystems, doesn't mean that the subfilesystems don't actually
> > > exist.
> > 
> > No, it does not. But it does mean that some applications that should know
> > about them won't know and will give even more confusing results.
> 
> How will they give more confusing results?  Please ellaborate.

I mean specifically the case of df and similar things. So far remote
filesystems generally return obviously invalid results so far. But when
they are made to return correct values for subfilesystem, these tools
need a way to find where those subfilesystems start.

--
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Attachment: signature.asc
Description: Digital signature