lkml.org 
[lkml]   [2005]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/8] VFS: per inode statfs (core)
    From
    Date
    > > > > > > 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/

    \
     
     \ /
      Last update: 2005-10-26 22:12    [W:0.027 / U:89.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site