> > (*) I got an internal complaint about missing the rename cookie with
> > FAN_REPORT_NAME, so I had to carry a small patch internally.
> > The problem is not that the rename cookie is really needed, but that without
> > the rename cookie, events can be re-ordered across renames and that can
> > generate some non-deterministic event sequences.
> >
> > So I am thinking of keeping the rename cookie in the kernel event just for
> > no-merge indication and then userspace can use object fid to match
> > MOVED_FROM/MOVED_TO events.
>
> Well, the event sequences are always non-deterministic due to event
> merging. So I'm somewhat surprised that rename events particularly matter.
> I suspect the code relying on "determinism" is buggy, it just perhaps
> doesn't manifest in practice for other event types...
>
Maybe I did not explain the issue correctly.
The use case is matching pairs of MOVED_FROM/MOVED_TO events,
regardless of re-ordering with other event types.
In inotify, both those events carry a unique cookie, so they are never merged
with any other event type. The events themselves have the same cookie but
differ in filename, so are not merged.
In vfs code, fsnotify_move() is called under lock_rename() so:
1. Cross-parent MOVED event pairs are fully serialized
2. Same-parent MOVED event pairs are serialized in each parent...
3. ... but may be interleaved with MOVED event pairs in other parents
4. Subsequent MOVED event pairs of the same object are also
serialized per moved object
The rules above apply to fanotify MOVED events as well, but in fanotify,
because cookie is not stored in event and not participating in merge,
the MOVED_FROM/MOVED_TO events can be merged with other
event types and therefore re-ordered amongst themselves.
Our userspace service needs to be able to match MOVED_FROM/MOVED_TO
event pairs for several reasons and I believe this is quite a common
need.
This need is regardless of re-ordering the MOVED_FROM/MOVED_TO event
pair with other events such as CREATE/DELETE.
To mention a concrete example, if listener can reliably match a MOVED pair
and the DFID/FID object is found locally in the MOVED_TO name, then a remote
command to the backup destination to rename from the MOVED_FROM
name can be attempted.
All we need to do in order to allow for fanotify listeners to use DFID/FID
to match MOVED_FROM/MOVED_TO interleaved event pairs is to
NOT merge MOVED events with other event types if group has all
these flags (FAN_REPORT_DFID_NAME | FAN_REPORT_FID).
IMO, there is not much to lose with this minor change in event merge
condition and there is much to gain.
The documentation is a bit more tricky, but it is generally sufficient
to document that MOVED_FROM/MOVED_TO events on the same
object (FID) are not re-ordered amongst themselves with respective
group flag combination.
Do you agree?
Thanks,
Amir.
