Dave Chinner wrote on Mon, Apr 24, 2023 at 08:40:45AM +1000: > This doesn't actually introduce non-blocking getdents operations, so > what's the point? If it just shuffles the getdents call off to a > background thread, why bother with io_uring in the first place? As said in the cover letter my main motivation really is simplifying the userspace application: - style-wise, mixing in plain old getdents(2) or readdir(3) in the middle of an io_uring handling loop just feels wrong; but this may just be my OCD talking. - in my understanding io_uring has its own thread pool, so even if the actual getdents is blocking other IOs can progress (assuming there is less blocked getdents than threads), without having to build one's own extra thread pool next to the uring handling. Looking at io_uring/fs.c the other "metadata related" calls there also use the synchronous APIs (renameat, unlinkat, mkdirat, symlinkat and linkat all do), so I didn't think of that as a problem in itself. > Filesystems like XFS can easily do non-blocking getdents calls - we > just need the NOWAIT plumbing (like we added to the IO path with > IOCB_NOWAIT) to tell the filesystem not to block on locks or IO. > Indeed, filesystems often have async readahead built into their > getdents paths (XFS does), so it seems to me that we really want > non-blocking getdents to allow filesystems to take full advantage of > doing work without blocking and then shuffling the remainder off to > a background thread when it actually needs to wait for IO.... I believe that can be done without any change of this API, so that'll be a very welcome addition when it is ready; I don't think the adding the uring op should wait on this if we can agree a simple wrapper API is good enough (or come up with a better one if someone has a Good Idea) (looking at io_uring/rw.c for comparison, io_getdents() will "just" need to be adjusted to issue an async req if IO_URING_F_NONBLOCK is set, and the poll/retry logic sorted out) Thanks, -- Dominique Martinet | Asmadeus
