new stat*fs-like syscall?
in [Kernel]
|
Prev: [PATCH] tps65023: Allow registering similar TPS65021
Next: [PATCH] video: simplify strlen()==0 check in fb_get_options()
From: Christoph Hellwig on 25 Jun 2010 14:50 On Fri, Jun 25, 2010 at 02:16:38PM -0400, Christoph Hellwig wrote: > On Fri, Jun 25, 2010 at 10:52:05AM -0700, Ulrich Drepper wrote: > > there are not that many flags which are portable and available on all > > the platforms. Look at /usr/include/bits/statvfs.h for what has to be > > supported and the values to use. If the values the kernel will use > > differ I'd have to (unnecessarily) convert the values. If some values > > are missing/not supported I still would have to use /proc/mounts and > > nothing is gained. > > I don't quite get what ST_WRITE is supposed to mean. All but that one > can be supported trivially. In addition ST_APPEND and ST_IMMUTABLE are rather puzzling. Do you really want these to mean if the file we call statfs on have the immutable/append only bits set? That is mixing two bits of stat information into statfs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ulrich Drepper on 25 Jun 2010 15:50 On Fri, Jun 25, 2010 at 11:45, Christoph Hellwig <hch(a)infradead.org> wrote: > I don't quite get what ST_WRITE is supposed to mean. All but that one > can be supported trivially. ST_WRITE comes elsewhere. We don't use it on Linux. > In addition ST_APPEND and ST_IMMUTABLE are rather puzzling. Do you > really want these to mean if the file we call statfs on have the > immutable/append only bits set? That is mixing two bits of stat > information into statfs? Ignore these as well, they also has a different source. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 26 Jun 2010 06:20 Nick Piggin <npiggin(a)suse.de> writes: > Other than types, other differences are: > - statvfs(2) has is f_frsize, which seems fairly useless. > - statvfs(2) has f_favail. > - statfs(2) f_bsize is optimal transfer block, statvfs(2) f_bsize is fs > block size. The latter could be useful for disk space algorithms. > Both can be ill defned. > - statvfs(2) lacks f_type. > > Is there anything more we should add here? Samba wants a capabilities > field, with things like sparse files, quotas, compression, encryption, > case preserving/sensitive. I wonder if it would make sense to export the time stamp granuality of the time stamps? We already have this information internally, and it might allow user land to optimize its stat frequency or comparison. Some file systems also have quotas with "project ids". Maybe add that too? I think NTFS et.al. also have some more time stamps, but not sure there's enough space for that. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: J. R. Okajima on 26 Jun 2010 09:00 Christoph Hellwig: > That's really job for a pathconf system call that allows quering random > paramters. Do you mean it should be implemented such like this? vfs_pathconf(struct dentry, int parm) --> return d_sb->s_op->pathconf(parm) I am afraid it is overdesign because the actual parameter(for FS) is _PC_LINK_MAX only. All other params are already handled by VFS, glibc or sb->statfs. J. R. Okajima (pathconf(3) parameters from the manual) _PC_LINK_MAX returns the maximum number of links to the file. If fd or path refer to a direc- tory, then the value applies to the whole directory. The corresponding macro is _POSIX_LINK_MAX. _PC_MAX_CANON returns the maximum length of a formatted input line, where fd or path must refer to a terminal. The corresponding macro is _POSIX_MAX_CANON. _PC_MAX_INPUT returns the maximum length of an input line, where fd or path must refer to a ter- minal. The corresponding macro is _POSIX_MAX_INPUT. _PC_NAME_MAX returns the maximum length of a filename in the directory path or fd that the pro- cess is allowed to create. The corresponding macro is _POSIX_NAME_MAX. _PC_PATH_MAX returns the maximum length of a relative pathname when path or fd is the current working directory. The corresponding macro is _POSIX_PATH_MAX. _PC_PIPE_BUF returns the size of the pipe buffer, where fd must refer to a pipe or FIFO and path must refer to a FIFO. The corresponding macro is _POSIX_PIPE_BUF. _PC_CHOWN_RESTRICTED returns non-zero if the chown(2) call may not be used on this file. If fd or path refer to a directory, then this applies to all files in that directory. The corre- sponding macro is _POSIX_CHOWN_RESTRICTED. _PC_NO_TRUNC returns non-zero if accessing filenames longer than _POSIX_NAME_MAX generates an error. The corresponding macro is _POSIX_NO_TRUNC. _PC_VDISABLE returns non-zero if special character processing can be disabled, where fd or path must refer to a terminal. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ulrich Drepper on 26 Jun 2010 11:00
On Sat, Jun 26, 2010 at 02:35, Christoph Hellwig <hch(a)infradead.org> wrote: > That's really job for a pathconf system call that allows quering random > paramters. Linus has always objected to sysconf/pathconf-like syscalls. If you get it in I'm all for it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |