Stefan Roesch wrote on Tue, Dec 21, 2021 at 08:40:01AM -0800: > This series adds support for getdents64 in liburing. The intent is to > provide a more complete I/O interface for io_uring. [reminder: This series was dropped a year ago after Al Viro rightly pointed out that we can't just pass an arbitrary offset to iterate_dir as offset validation is costly and not always possible at all] I'm digging an old topic here because I was looking at trying io_uring on a toy project (specifically, exporting infos out of /sys/fs/cgroup recursively), but was partly held back by the lack of getdents or equivalent interface for the crawler part -- and existing bricks like fts or nftw predate openat interfaces and just didn't appeal to me, but in general just mixing in io_uring and synchronous getdents sounded a bit of a pain. Given it's been over a year I guess it's not such a much needed feature, but when you're centering your program loop around the ring having the occasional getdents/readdir call is a bit cumbersome. This is probably a naive idea, but would it make sense discussing just making it fit the current getdents API: Given the problem seems to be revalidating the offset, since the main usecase is probably to just go through a directory, perhaps the file's offset could be updated just like the real call and offset validation be skipped if the parameter is equal to the file's offset? Giving a different offset would be equivalent to lseek + getdents and update the position as well, so e.g. rewinding the directory with a seek 0 would work if an application needs to check a directory's content multiple times. Heck, seek to any offset other than 0 could just be refused for any sane usage, it just doesn't make sense to use anything else in practice; that'd make it a defacto "dumb getdents + rewinddir". The API could be made simpler to use/clear about expectations by making the last parameter "bool rewind_first" instead of an offset (or I guess a flag with just a single valid bit if we were to really implement this) This isn't very io_uring-like, but it'd allow for an io_uring-centric program to also handle some directory processing, and wouldn't expose anything that's not currently already possible to do (as long as each processed op brings in its own context, the only "race" I can see in iterate_dir is that file->f_pos can go back to a previously also valid position if some iterations are faster than others, assuming it's an atomic access, and that'd probably warrant a READ/WRITE_ONCE or something.. but that's not a new problem, user threads can already hammer getdents in parallel on a single fd if they want useless results) What do you think? I'm just asking with a toy in mind so it's not like I have any strong opinion, but I'd be happy to rework Stefan's patches if it looks like it might make sense. (And if the consensus is that this will make hell break loose I'll just forget about it before sinking more time in it, just catching up was fun enough!) Cheers, -- Dominique Martinet | Asmadeus
