Introduce fallocate query support mode

That being said, I really detest adding weird query modes to random syscalls. We should expose capabilities through the interface that was designed for such things: (f)pathconf, as there are a lot more important parameters we currently fail to expose to userspace to start with.

This seems to miss any explanation and 6 out of 7 patches.

That being said, I really detest adding weird query modes to random syscalls. We should expose capabilities through the interface that was designed for such things: (f)pathconf, as there are a lot more important parameters we currently fail to expose to userspace to start with.

Quoted 1 line · Christoph Hellwig

This seems to miss any explanation and 6 out of 7 patches.

See linux-fsdevel for entire patch set.
https://www.spinics.net/lists/linux-fsdevel/msg115740.html

(f)pathconf on it's own is useless because I need to get this information directly from the file system. Supported fallocate modes can differ with inode flags (encrypted files, extent/indirect based files on ext4). I also need in-kernel interface.

Return all fallcoate modes supported by xfs file system.

Cc [email protected]

Signed-off-by Lukas Czerner <[email protected]>

---
 fs/xfs/xfs_file.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

fs/xfs/xfs_file.c +2 -1

index ebdd0bd..85e06c6 100644
@@ -746,7 +746,8 @@ xfs_file_write_iter(
 #define	XFS_FALLOC_FL_SUPPORTED						\
 		(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |		\
 		 FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |	\
-		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE)
+		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE |	\
+		 FALLOC_FL_QUERY_SUPPORT | FALLOC_FL_PREALLOC_RANGE)
 
 STATIC long
 xfs_file_fallocate(

fs/xfs/xfs_file.c +1 -0

+
 	xfs_ilock(ip, iolock);
 	error = xfs_break_layouts(inode, &iolock);
 	if (error)

Signature · 6 lines

2.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 23 lines · Lukas Czerner

Return all fallcoate modes supported by xfs file system.

Cc [email protected]

Signed-off-by Lukas Czerner <[email protected]>

---
fs/xfs/xfs_file.c | 6 +++++-

1 file changed, 5 insertions(+), 1 deletion(-)

fs/xfs/xfs_file.c +2 -1

index ebdd0bd..85e06c6 100644
@@ -746,7 +746,8 @@ xfs_file_write_iter(
 #define	XFS_FALLOC_FL_SUPPORTED						\
 		(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |		\
 		 FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |	\
-		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE)
+		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE |	\
+		 FALLOC_FL_QUERY_SUPPORT | FALLOC_FL_PREALLOC_RANGE)
 

STATIC long
xfs_file_fallocate(

fs/xfs/xfs_file.c xfs_file_fallocate( · line 773

Quoted 5 lines

fs/xfs/xfs_file.c +2 -0

@@ -768,6 +769,9 @@ xfs_file_fallocate(
 	if (mode & ~XFS_FALLOC_FL_SUPPORTED)
 		return -EOPNOTSUPP;
 
+	if (mode & FALLOC_FL_QUERY_SUPPORT)
+		return XFS_FALLOC_FL_SUPPORTED;

Urk, manpage update describing the goals of the query interface and how this is supposed to work is needed.

Are we required to return only the mode flags that would reasonably be expected to work on this file, or the fs in general? Do we return zero if the file is immutable (I guess the fd has to be O_RDONLY?) or if the fs is readonly?

And like hch said, why not {f,}pathconf?

Quoted 1 line

And like hch said, why not {f,}pathconf?

The problem with pathconf() is that this is just made up by GlibC, and doesn't actually communicate with the kernel or the filesystem at all. For example, _PC_LINK_MAX does not return different values for ext2/ext4 filesystems based on feature flags, only what is hard-coded into GlibC based on the filesystem magic. This is not going to work as a per-file source of information.

For example, even though EXT4_LINK_MAX has been 65000 for many years, GlibC reports 32000 for an ext4 filesystem since it only uses the magic:

Quoted 11 lines · Andreas Dilger

Quoted 1 line

And like hch said, why not {f,}pathconf?

The problem with pathconf() is that this is just made up by GlibC, and doesn't actually communicate with the kernel or the filesystem at all. For example, _PC_LINK_MAX does not return different values for ext2/ext4 filesystems based on feature flags, only what is hard-coded into GlibC based on the filesystem magic. This is not going to work as a per-file source of information.

For example, even though EXT4_LINK_MAX has been 65000 for many years, GlibC reports 32000 for an ext4 filesystem since it only uses the magic:

Maybe the right answer is we should define a new pathconfat(2) system call which can be used as part of a C library's implementation of pathconf() and fpathconf()? glibc probably won't use it for years, of course. But we can at least provide the information via an interface which we can control, and which is capable of returning correct results?

- Ted

Maybe the right answer is we should define a new pathconfat(2) system call which can be used as part of a C library's implementation of pathconf() and fpathconf()? glibc probably won't use it for years, of course. But we can at least provide the information via an interface which we can control, and which is capable of returning correct results?

Quoted 6 lines · Theodore Ts'o

Maybe the right answer is we should define a new pathconfat(2) system call which can be used as part of a C library's implementation of pathconf() and fpathconf()? glibc probably won't use it for years, of course. But we can at least provide the information via an interface which we can control, and which is capable of returning correct results?

glibc is very fast at picking up new kernel interface these days as long as they aren't too controversial. Implementing a syscall that backs a function they implement should not be in the controversial category I think.

We have a significant backlog, but I don't expect opposition to patches implementing syscall wrappers which are just slightly generic (and pathconfat should really be fine).

Technically, pathconfat might be tricky to maintain if it's expected to be a variadic dispatcher function, and the accompanying UAPI header isn't very clean.

Quoted 7 lines · Florian Weimer

We have a significant backlog, but I don't expect opposition to patches implementing syscall wrappers which are just slightly generic (and pathconfat should really be fine).

Technically, pathconfat might be tricky to maintain if it's expected to be a variadic dispatcher function, and the accompanying UAPI header isn't very clean.

(f)pathconf is defined as:

       long fpathconf(int fd, int name);
       long pathconf(const char *path, int name);

so there really shouldn't be any issue.

Quoted 9 lines · Christoph Hellwig

Quoted 7 lines · Florian Weimer

We have a significant backlog, but I don't expect opposition to patches implementing syscall wrappers which are just slightly generic (and pathconfat should really be fine).

Technically, pathconfat might be tricky to maintain if it's expected to be a variadic dispatcher function, and the accompanying UAPI header isn't very clean.

Quoted 6 lines

(f)pathconf is defined as:

       long fpathconf(int fd, int name);
       long pathconf(const char *path, int name);

so there really shouldn't be any issue.

There might be some tricky bits will be if glibc feels it needs to override the values returned by the kernel (if it believes it may impose some limitations due to its implementation). Also, not all file systems will implement some or all pathconf parameters initially (or perhaps ever). So should the VFS be responsible for returning some intelligent defaults, or glibc?

Also, will application programs want to know whether they are getting kernel values versus glibc's best guess (which may be depedent on the kernel version, modulo distributions / handset/tablet vendors who might decide to backport the syscall to their kernels)?

It might be a good idea to come to a rough agreement (between the kernel and glibc devs) about how to handle some of these practical issues up front.

Cheers,

- Ted

_PC_NAME_MAX linux limits

_PC_REC_INCR_XFER_SIZE ?
_PC_REC_MAX_XFER_SIZE ?
_PC_REC_MIN_XFER_SIZE ? block size ?
_PC_REC_XFER_ALIGN per fs (block size)

_PC_ALLOC_SIZE_MIN per fs (block size)

Quoted 1 line · Lukas Czerner

_PC_NAME_MAX linux limits

Note that _PC_NAME_MAX is basically a lie. There are file systems which support longer names than 255 bytes. It's quite common for file systems which store names in UCS-2 or UTF-16 and have code point limit of 255, which translates to something larger after UTF-8 conversion in the kernel. This value is available today through statfs/f_namemax, but historically, the reported value was not correct.

But due to file bind mounts, any value the kernel can return is useless for application use anyway.

The only real user of this constant was readdir_r, and I've been trying to kill it (it's still in POSIX, but will be removed in a future edition).

Quoted 5 lines

_PC_REC_INCR_XFER_SIZE ?
_PC_REC_MAX_XFER_SIZE ?
_PC_REC_MIN_XFER_SIZE ? block size ?
_PC_REC_XFER_ALIGN per fs (block size)

NFS (and perhaps other network file systems) treats f_bsize to signal something similar. We had to remove f_bsize-based tuning from glibc as a result because the value is quite misleading for many workloads.

Quoted 1 line

_PC_ALLOC_SIZE_MIN per fs (block size)

Like the other size limits quoted above, the semantics are quite unclear. POSIX documents them mostly in the context of the RT extensions, so the acceptable values likely depend whether the application uses kernel-assisted aio, or aio based on userspace threads.

There might be some tricky bits will be if glibc feels it needs to override the values returned by the kernel (if it believes it may impose some limitations due to its implementation). Also, not all file systems will implement some or all pathconf parameters initially (or perhaps ever). So should the VFS be responsible for returning some intelligent defaults, or glibc?

Quoted 6 lines · Theodore Ts'o

There might be some tricky bits will be if glibc feels it needs to override the values returned by the kernel (if it believes it may impose some limitations due to its implementation). Also, not all file systems will implement some or all pathconf parameters initially (or perhaps ever). So should the VFS be responsible for returning some intelligent defaults, or glibc?

I'd prefer if we could export pathconfat directly on the glibc side, without any emulation, and have the application deal with ENOSYS.

We would use it to implement parts of pathconf/fpathconf if available, but I don't think we should copy the existing emulation for pathconfat because every time we add such emulation, it comes back to haunt us.

Quoted 26 lines · Lukas Czerner

Return all fallcoate modes supported by xfs file system.

Cc [email protected]

Signed-off-by Lukas Czerner <[email protected]>

---
 fs/xfs/xfs_file.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

fs/xfs/xfs_file.c +2 -1

index ebdd0bd..85e06c6 100644
@@ -746,7 +746,8 @@ xfs_file_write_iter(
 #define	XFS_FALLOC_FL_SUPPORTED						\
 		(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |		\
 		 FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |	\
-		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE)
+		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE |	\
+		 FALLOC_FL_QUERY_SUPPORT | FALLOC_FL_PREALLOC_RANGE)
 
 STATIC long
 xfs_file_fallocate(

@@ -768,6 +769,9 @@ xfs_file_fallocate(
 	if (mode & ~XFS_FALLOC_FL_SUPPORTED)
 		return -EOPNOTSUPP;
 

fs/xfs/xfs_file.c xfs_file_fallocate( · line 773

Quoted 2 lines

fs/xfs/xfs_file.c +2 -0

+	if (mode & FALLOC_FL_QUERY_SUPPORT)
+		return XFS_FALLOC_FL_SUPPORTED;

Urk, manpage update describing the goals of the query interface and how this is supposed to work is needed.

Are we required to return only the mode flags that would reasonably be expected to work on this file, or the fs in general? Do we return zero

if the file is immutable (I guess the fd has to be O_RDONLY?) or if the fs is readonly?

And like hch said, why not {f,}pathconf?

--D

Quoted 11 lines

fs/xfs/xfs_file.c +1 -0

+
 	xfs_ilock(ip, iolock);
 	error = xfs_break_layouts(inode, &iolock);
 	if (error)

Signature · 6 lines

2.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html