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

[Jan Hudec <bulb@ucw.cz>]

On Wed, Oct 26, 2005 at 21:17:23 +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. And it cannot be fixed (without loss of functionality) unless
you somehow tell it where the boundary of the subfilesystem lies.

> 'stat -f .': actually works

Sure it does. I don't expect many people to use that manually though.

> foo-filemanager: before copying a file or directory tree, checks for
> free space in destination directory

While most others simply don't care -- if it fails, it fails. Looking up the
free space beforehand is only a heurisitics anyway, as the free space can
change between the stat and the copy anyway.

> 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.

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

Attachment: signature.asc
Description: Digital signature