> > > > > > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
