On Mon 10-06-24 16:21:39, Amir Goldstein wrote: > On Mon, Jun 10, 2024 at 2:50 PM Andrey Albershteyn <aalbersh@xxxxxxxxxx> wrote: > > > > On 2024-06-10 12:19:50, Amir Goldstein wrote: > > > On Mon, Jun 10, 2024 at 11:17 AM Andrey Albershteyn <aalbersh@xxxxxxxxxx> wrote: > > > > > > > > But those special file's inodes still will not be accounted by the > > > > quota during initial project setup (xfs_quota will skip them), would > > > > it worth it adding new syscalls anyway? > > > > > > > > > > Is it worth it to you? > > > > > > Adding those new syscalls means adding tests and documentation > > > and handle all the bugs later. > > > > > > If nobody cared about accounting of special files inodes so far, > > > there is no proof that anyone will care that you put in all this work. > > > > I already have patch and some simple man-pages prepared, I'm > > wondering if this would be useful for any other usecases > > Yes, I personally find it useful. > I have applications that query the fsx_xflags and would rather > be able to use O_PATH to query/set those flags, since > internally in vfs, fileattr_[gs]et() do not really need an open file. Well, Christian doesn't like [1] how much functionality is actually available through O_PATH fds because it kind of makes them more and more similar to normal fds and that's apparently undesirable for some usecases (for security reasons). So I don't think he'd like to have *another* functionality accepted for O_PATH fds :) But he can speak for himself... Honza [1] https://lore.kernel.org/all/20240412-labeln-filmabend-42422ec453d7@brauner [2] https://lore.kernel.org/all/20240430-machbar-jogginganzug-7fd3cff2c3ed@brauner -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
