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.
Signed-off-by: Miklos Szeredi <[email protected]>
Index: linux/include/linux/fs.h
===================================================================
--- linux.orig/include/linux/fs.h 2005-10-24 14:13:40.000000000 +0200
+++ linux/include/linux/fs.h 2005-10-24 14:21:37.000000000 +0200
@@ -1012,6 +1012,7 @@ struct inode_operations {
ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*removexattr) (struct dentry *, const char *);
+ int (*statfs) (struct dentry *, struct kstatfs *);
};
struct seq_file;
@@ -1256,7 +1257,9 @@ extern int may_umount_tree(struct vfsmou
extern int may_umount(struct vfsmount *);
extern long do_mount(char *, char *, char *, unsigned long, void *);
+/* vfs_statfs() is deprecated, use vfs_dentry_statfs() instead */
extern int vfs_statfs(struct super_block *, struct kstatfs *);
+extern int vfs_dentry_statfs(struct dentry *, struct kstatfs *);
#define FLOCK_VERIFY_READ 1
#define FLOCK_VERIFY_WRITE 2
Index: linux/fs/open.c
===================================================================
--- linux.orig/fs/open.c 2005-10-24 14:13:40.000000000 +0200
+++ linux/fs/open.c 2005-10-24 14:21:37.000000000 +0200
@@ -49,12 +49,35 @@ int vfs_statfs(struct super_block *sb, s
EXPORT_SYMBOL(vfs_statfs);
-static int vfs_statfs_native(struct super_block *sb, struct statfs *buf)
+int vfs_dentry_statfs(struct dentry *dentry, struct kstatfs *buf)
+{
+ struct inode *inode = dentry->d_inode;
+ int retval;
+
+ if (inode->i_op && inode->i_op->statfs) {
+ memset(buf, 0, sizeof(*buf));
+ retval = security_sb_statfs(inode->i_sb);
+ if (retval)
+ return retval;
+
+ retval = inode->i_op->statfs(dentry, buf);
+
+ if (retval == 0 && buf->f_frsize == 0)
+ buf->f_frsize = buf->f_bsize;
+ } else
+ retval = vfs_statfs(inode->i_sb, buf);
+
+ return retval;
+}
+
+EXPORT_SYMBOL(vfs_dentry_statfs);
+
+static int vfs_statfs_native(struct dentry *dentry, struct statfs *buf)
{
struct kstatfs st;
int retval;
- retval = vfs_statfs(sb, &st);
+ retval = vfs_dentry_statfs(dentry, &st);
if (retval)
return retval;
@@ -92,12 +115,12 @@ static int vfs_statfs_native(struct supe
return 0;
}
-static int vfs_statfs64(struct super_block *sb, struct statfs64 *buf)
+static int vfs_statfs64(struct dentry *dentry, struct statfs64 *buf)
{
struct kstatfs st;
int retval;
- retval = vfs_statfs(sb, &st);
+ retval = vfs_dentry_statfs(dentry, &st);
if (retval)
return retval;
@@ -127,7 +150,7 @@ asmlinkage long sys_statfs(const char __
error = user_path_walk(path, &nd);
if (!error) {
struct statfs tmp;
- error = vfs_statfs_native(nd.dentry->d_inode->i_sb, &tmp);
+ error = vfs_statfs_native(nd.dentry, &tmp);
if (!error && copy_to_user(buf, &tmp, sizeof(tmp)))
error = -EFAULT;
path_release(&nd);
@@ -146,7 +169,7 @@ asmlinkage long sys_statfs64(const char
error = user_path_walk(path, &nd);
if (!error) {
struct statfs64 tmp;
- error = vfs_statfs64(nd.dentry->d_inode->i_sb, &tmp);
+ error = vfs_statfs64(nd.dentry, &tmp);
if (!error && copy_to_user(buf, &tmp, sizeof(tmp)))
error = -EFAULT;
path_release(&nd);
@@ -165,7 +188,7 @@ asmlinkage long sys_fstatfs(unsigned int
file = fget(fd);
if (!file)
goto out;
- error = vfs_statfs_native(file->f_dentry->d_inode->i_sb, &tmp);
+ error = vfs_statfs_native(file->f_dentry, &tmp);
if (!error && copy_to_user(buf, &tmp, sizeof(tmp)))
error = -EFAULT;
fput(file);
@@ -186,7 +209,7 @@ asmlinkage long sys_fstatfs64(unsigned i
file = fget(fd);
if (!file)
goto out;
- error = vfs_statfs64(file->f_dentry->d_inode->i_sb, &tmp);
+ error = vfs_statfs64(file->f_dentry, &tmp);
if (!error && copy_to_user(buf, &tmp, sizeof(tmp)))
error = -EFAULT;
fput(file);
Index: linux/fs/nfsd/vfs.c
===================================================================
--- linux.orig/fs/nfsd/vfs.c 2005-10-24 12:11:04.000000000 +0200
+++ linux/fs/nfsd/vfs.c 2005-10-24 14:21:37.000000000 +0200
@@ -1740,7 +1740,7 @@ int
nfsd_statfs(struct svc_rqst *rqstp, struct svc_fh *fhp, struct kstatfs *stat)
{
int err = fh_verify(rqstp, fhp, 0, MAY_NOP);
- if (!err && vfs_statfs(fhp->fh_dentry->d_inode->i_sb,stat))
+ if (!err && vfs_dentry_statfs(fhp->fh_dentry, stat))
err = nfserr_io;
return err;
}
Index: linux/fs/nfsd/nfs4xdr.c
===================================================================
--- linux.orig/fs/nfsd/nfs4xdr.c 2005-10-24 12:11:04.000000000 +0200
+++ linux/fs/nfsd/nfs4xdr.c 2005-10-24 14:21:37.000000000 +0200
@@ -1311,7 +1311,7 @@ nfsd4_encode_fattr(struct svc_fh *fhp, s
if ((bmval0 & (FATTR4_WORD0_FILES_FREE | FATTR4_WORD0_FILES_TOTAL)) ||
(bmval1 & (FATTR4_WORD1_SPACE_AVAIL | FATTR4_WORD1_SPACE_FREE |
FATTR4_WORD1_SPACE_TOTAL))) {
- status = vfs_statfs(dentry->d_inode->i_sb, &statfs);
+ status = vfs_dentry_statfs(dentry, &statfs);
if (status)
goto out_nfserr;
}
Index: linux/fs/compat.c
===================================================================
--- linux.orig/fs/compat.c 2005-10-24 12:11:04.000000000 +0200
+++ linux/fs/compat.c 2005-10-24 14:21:37.000000000 +0200
@@ -167,7 +167,7 @@ asmlinkage long compat_sys_statfs(const
error = user_path_walk(path, &nd);
if (!error) {
struct kstatfs tmp;
- error = vfs_statfs(nd.dentry->d_inode->i_sb, &tmp);
+ error = vfs_dentry_statfs(nd.dentry, &tmp);
if (!error && put_compat_statfs(buf, &tmp))
error = -EFAULT;
path_release(&nd);
@@ -185,7 +185,7 @@ asmlinkage long compat_sys_fstatfs(unsig
file = fget(fd);
if (!file)
goto out;
- error = vfs_statfs(file->f_dentry->d_inode->i_sb, &tmp);
+ error = vfs_dentry_statfs(file->f_dentry, &tmp);
if (!error && put_compat_statfs(buf, &tmp))
error = -EFAULT;
fput(file);
@@ -235,7 +235,7 @@ asmlinkage long compat_sys_statfs64(cons
error = user_path_walk(path, &nd);
if (!error) {
struct kstatfs tmp;
- error = vfs_statfs(nd.dentry->d_inode->i_sb, &tmp);
+ error = vfs_dentry_statfs(nd.dentry, &tmp);
if (!error && put_compat_statfs64(buf, &tmp))
error = -EFAULT;
path_release(&nd);
@@ -256,7 +256,7 @@ asmlinkage long compat_sys_fstatfs64(uns
file = fget(fd);
if (!file)
goto out;
- error = vfs_statfs(file->f_dentry->d_inode->i_sb, &tmp);
+ error = vfs_dentry_statfs(file->f_dentry, &tmp);
if (!error && put_compat_statfs64(buf, &tmp))
error = -EFAULT;
fput(file);
Index: linux/kernel/acct.c
===================================================================
--- linux.orig/kernel/acct.c 2005-10-24 12:11:05.000000000 +0200
+++ linux/kernel/acct.c 2005-10-24 14:21:37.000000000 +0200
@@ -116,7 +116,7 @@ static int check_free_space(struct file
spin_unlock(&acct_globals.lock);
/* May block */
- if (vfs_statfs(file->f_dentry->d_inode->i_sb, &sbuf))
+ if (vfs_dentry_statfs(file->f_dentry, &sbuf))
return res;
suspend = sbuf.f_blocks * SUSPEND;
resume = sbuf.f_blocks * RESUME;
On Mon, Oct 24, 2005 at 06:55:19PM +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.
NAK, and if FUSE needs that for something, it's *badly* misdesigned.
> > 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.
Miklos
On Tue, Oct 25, 2005 at 07:44:30 +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.
--
Jan 'Bulb' Hudec <[email protected]>
> > > > 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
'stat -f .': actually works
foo-filemanager: before copying a file or directory tree, checks for
free space in destination directory
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.
Miklos
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 <[email protected]>
> > > > > > 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
On Wed, 26 Oct 2005, Miklos Szeredi wrote:
> > > 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.
Indeed. ncpfs always returns 0 which for example breaks OpenOffice
amongst many other applications when your home directory is on ncpfs. We
locally patch ncpfs to always return 2GiB free space which always makes
things work. (-:
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
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 <[email protected]>
> 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.
Sorry, I still don't get it.
'df path' looks up the mountpoint. Fine, no problem with that.
Displays it in in column 'Mounted on'. Then goes on to do
statfs(path), and display the results.
Can you please explain why you think that's wrong? It displayed the
free space in the directory I _aked_it_. It displayed the mountpoint
under which this path happens to be.
If I want to find out the free space immediately under the mountpoint,
I can do 'df mountpoint' or just 'df'. But that's not what the user
is interested in when it does 'df path', the user is interested in the
free space under 'path'.
What is the loss of functionality? For mounts not having
subfilesystems, there will be _no_change_whatsoever_!
> > 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.
Why? What if that info is simply not available?
You are talking about missing functionality not _loss_ of
functionality.
Yes, possibility for finding out where subfilesystems are located
_will_ be missing for such filesystems as sshfs. Is that a reason for
asuming subfilesystems don't exsist, and not allowing already existing
tools (filemanagers, openoffice, etc) to make use of a statfs() system
call which can return _meaningful_ results for subfilesystems?
Miklos
to den 27.10.2005 klokka 10:23 (+0200) skreiv Miklos Szeredi:
> Yes, possibility for finding out where subfilesystems are located
> _will_ be missing for such filesystems as sshfs.
Why? Can't lookup() notice the change in remote st_dev as you cross the
filesystem boundary?
For NFS the plan is to automatically submount such remote
subfilesystems. That fixes a host of problems including the one that you
mention w.r.t. statfs, the problem of potential duplicate inode numbers,
etc.
Cheers,
Trond
> > Yes, possibility for finding out where subfilesystems are located
> > _will_ be missing for such filesystems as sshfs.
>
> Why? Can't lookup() notice the change in remote st_dev as you cross the
> filesystem boundary?
a) sftp is path based protocol, there's no separate lookup
b) sftp doesn't transfer st_ino or st_dev, they are both made up on
the client side
> For NFS the plan is to automatically submount such remote
> subfilesystems. That fixes a host of problems including the one that you
> mention w.r.t. statfs, the problem of potential duplicate inode numbers,
> etc.
That is fine. It's clearly a superior sulution when the info is
available. With sshfs the server simply doesn't care about mounts,
and so this is basically out of the question.
Miklos