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.
On Mon, Sep 18, 2017 at 10:56:51AM -0700, Christoph Hellwig wrote:
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
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.
(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.
That's why I though fallocate is the convenient place to put this. I
have not looked to it, but other option might be to use fstat to get
this.
-Lukas
On Tue, Sep 19, 2017 at 10:15:38AM +0200, Lukas Czerner wrote:
On Mon, Sep 18, 2017 at 10:56:51AM -0700, Christoph Hellwig wrote:
quoted
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
But only one made it to linux-xfs, so please fix your patch sending.
(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.
And that is exactly what I want you to do: finally bite the bullet
and add pathconf inode operation.