On 4/4/23 3:21?AM, Jan Kara wrote: > On Mon 03-04-23 11:23:25, Jens Axboe wrote: >> On 4/3/23 11:15?AM, Amir Goldstein wrote: >>>> On 4/3/23 11:00?AM, Amir Goldstein wrote: >>>> io_uring does do it for non-polled IO, I don't think there's much point >>>> in adding it to IOPOLL however. Not really seeing any use cases where >>>> that would make sense. >>>> >>> >>> Users subscribe to fsnotify because they want to be notified of changes/ >>> access to a file. >>> Why do you think that polled IO should be exempt? >> >> Because it's a drastically different use case. If you're doing high >> performance polled IO, then you'd never rely on something as slow as >> fsnotify to tell you of any changes that happened to a device or file. >> That would be counter productive. > > Well, I guess Amir wanted to say that the application using fsnotify > is not necessarily the one doing high performance polled IO. You could > have e.g. data mirroring application A tracking files that need > mirroring to another host using fsnotify and if some application B > uses high performance polled IO to modify a file, application A could > miss the modified file. Sure, but what I'm trying to say is that if you're using polled IO, you're doing a custom setup anyway and the likelihood of needing fsnotify is slim to none. It'd certainly be in your best interesting to NOT rely on that, for performance reasons. And the latter is presumably why you'd using polled IO to begin with. > That being said if I look at exact details, currently I don't see a > very realistic usecase that would have problems (people don't depend > on FS_MODIFY or FS_ACCESS events too much, usually they just use > FS_OPEN / FS_CLOSE), which is likely why nobody reported these issues > yet :). The only report I got on io_uring and fsnotify was someone writing a buffered log with it, and noticing that tail doesn't work if you don't have fsnotify access notifications. Open/close would not be enough there. I'd much rather make fsnotify opt-in for io_uring than have it on by default, as it's quite the cycler consumer for IRQ based workloads right now. And that's without even having any watches on the file... -- Jens Axboe
