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

[Miklos Szeredi]

> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/