Messages in this thread | | | Date | Fri, 10 Oct 2003 01:22:48 +0100 | From | viro@parcelfa ... | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
On Thu, Oct 09, 2003 at 04:19:29PM -0700, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Linus Torvalds wrote: > > > User space shouldn't know or care about frsize, and it doesn't even > > necessarily make any sense on a lot of filesystems, so make it easy for > > the user. It's not as if the rounding errors really matter. > > There have been numerous requests to add a statvfs syscall, at least > made to me. The problem is that the emulation through statfs cannot be > optimal. The emulation has to get all kinds of additional information > (like mount flags) which in some cases lead to hangs or delays.
Umm... I don't see anything equivalent to statfs(2) ->f_type in statvfs(2). ->f_frsize makes no sense for practically all filesystems we support. ->f_namemax is not well-defined ("maximum filename length" as in "you won't see filenames longer than..." or "attempt to create a file with name longer than... will fail" or "longer than that and I'm truncating"; and that is aside of lovely questions about the meaning of "length" - strlen()? number of multibyte characters accepted by that fs? something else?) ->f_fsid is also practically undefined (and left 0 by practically every fs, so no userland code can do anything useful with it). ->f_flag might be useful, all right. However, I'd like to see real-world examples of code (Solaris, whatever) that would use it in any meaningful way...
Conclusion: if we care about something like statvfs(), it should *not* have the statvfs() interface. - 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/
| |