Messages in this thread | | | Subject | Re: [PATCH 2/8] VFS: per inode statfs (core) | From | Miklos Szeredi <> | Date | Wed, 26 Oct 2005 22:10:09 +0200 |
| |
> > > > > > 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.
> > '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.
Being a heuristic doesn't prevent it from being used. And if you have one subfilesystem with zero free space, and one with lots, you _will_ get burned if statfs() happens to report the zero space for every path within the mount.
> > 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.
Miklos - 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/
| |