On Thu, Dec 10, 2020 at 1:43 PM Jan Kara <jack@xxxxxxx> wrote: > > Hi Amir! > > On Wed 09-12-20 21:14:53, Amir Goldstein wrote: > > I have a use case with a listener that uses FAN_REPORT_FID mode. > > (fid is an index to a db). > > Most of the time fid can be resolved to the path and that is sufficient. > > If it cannot, the file will be detected by a later dir scan. > > > > I find that with most of the events this use case can handle the events > > efficiently without the name info except for FAN_CREATE. > > > > For files, with most applications, FAN_CREATE will be followed by > > some other event with the file fid, but it is not guaranteed. > > For dirs, a single FAN_CREATE event is more common. > > > > I was thinking that a FAN_CREATE_SELF event could be useful in some > > cases, but I don't think it is a must for closing functional gaps. > > For example, another group could be used with FAN_REPORT_DFID_NAME > > to listen on FAN_CREATE events only, or on FAN_CREATE (without name) > > the dir can be scanned, but it is not ideal. > > > > Before composing a patch I wanted to ask your opinion on the > > FAN_CREATE_SELF event. Do you have any thoughts on this? > > Well, generating FAN_CREATE_SELF event is kind of odd because you have no > mark placed on the inode which is being created. So it would seem more > logical to me that dirent events - create, move, delete - could provide you > with a FID of object that is affected by the operation (i.e., where DFID + > name takes you). That would have to be another event info type. FAN_CREATE_SELF makes sense for a filesystem mark. I forgot to mention that in the description of my use case. It also makes sense to API IMO because of symmetry with delete and move self vs. a completely new type of event. The application is maintaining a map with entries per accessed file indexed by fid. When an object appears on the fs, it would have been nice to be able to update the map right away, but it is not a deal breaker if it is updated later when the object is observed in another event. > > BTW, what's the problem with just using FAN_REPORT_DFID_NAME? You don't > want to pay the cost of looking up & copying DFID+name instead of FID for > cases you don't care about? Is there such a significant difference? That is the reason. Currently, the application uses FAN_REPORT_DFID_NAME, but I observed that with some configurations, name info is ONLY relevant for FAN_CREATE events. For those configurations, if we had FAN_CREATE_SELF, name info copying, variable size event allocation, less efficient merge, all of those could be avoided. How much does it actually save? I don't know. So as I said, I see it as a "nice to have" event, certainly not a must, but it can help optimize some workloads. The honest truth is that I think if I try hard enough I will be able to find a corner use case where FAN_CREATE_SELF can actually help to close a functional gap (or the new type of create event that you mentioned), but I am lazy try, so I try to use these arguments instead: The API documentation should be pretty straight forward and natural. The implementation should be trivial. So the question is - Why not? Thanks, Amir.
