Date: Sun, 03 Jan 2016 13:36:36 -0800 From: Jordan Hubbard <jordanhubbard@icloud.com> To: Mark Felder <feld@FreeBSD.org> Cc: Chris Stankevitz <chris@stankevitz.com>, FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Monitoring FS changes Message-ID: <046580B0-BF8E-4A83-B1BB-28C632B1B9B5@icloud.com> In-Reply-To: <1451855317.3739776.481776018.64F6C4D9@webmail.messagingengine.com> References: <5684D810.6070700@stankevitz.com> <1451855317.3739776.481776018.64F6C4D9@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 3, 2016, at 1:08 PM, Mark Felder <feld@FreeBSD.org> wrote: >=20 > If someone, anyone out there is capable of bringing us something that > does scale it would be greatly appreciated. Lots of nice Linux = software > uses this, but when they do port to FreeBSD we have to do full > filesystem scans. It's such a waste. I=E2=80=99ve been pondering this for awhile since a lot of interesting = enterprise features require a working filesystem change notification = mechanism that scales to thousands or even millions of files (how did we = bump into the 32 bit NFS file handle problem at iXsystems? Somebody = tried to share more than 4 billion files over NFS - Enterprise folks do = some crazy s**t!). The big question is less whether it=E2=80=99s possible and more what = kind of mechanism people will find palatable. The OS X FSEvents = mechanism works reasonably well and is used constantly to trigger things = like spotlight search indexing and such, and I was by no means involved = in its creation at Apple so I can only speak peripherally to the = implementation, but it seems like it took a fairly long time for it to = become =E2=80=9Clight weight=E2=80=9D enough to use without the overhead = being punitive. Any similar mechanism in FreeBSD would also have to go = through some evolutionary performance iterations - do people want it = badly enough to invest in it long-term? I don=E2=80=99t know, but I do = know that a long-term investment would be necessary to really make it = work well and provide all of the appropriate APIs for talking to it. I think we can probably all agree that Linux inotify wouldn=E2=80=99t be = worth the trouble. =46rom the wikipedia page: =E2=80=A2 Inotify does not support recursively watching = directories, meaning that a separate inotify watch must be created for = every subdirectory.[4] =E2=80=A2 Inotify does report some but not all events in sysfs = and procfs. =E2=80=A2 Notification via inotify requires the kernel to be = aware of all relevant filesystem events, which is not always possible = for networked filesystems such as NFS where changes made by one client = are not immediately broadcast to other clients. =E2=80=A2 Rename events are not handled directly; i.e., inotify = issues two separate events that must be examined and matched in a = context of potential race conditions. I think the first issue alone is a deal killer. Having to walk the = filesystem tree posting notifications on every [new] directory just to = watch a filesystem in its entirety would be pretty onerous and = failure-prone to boot. By contrast: = https://en.wikipedia.org/wiki/FSEvents This is also not to say that I would expect anything in FreeBSD to be = API-compatible (though the upstream clients would probably grumble at = yet another notification mechanism API to #ifdef into their code), = simply that there are only so many design patterns to follow. A = filesystem change is a filesystem change. Everything beyond that is = just a glorified pub/sub mechanism. Assuming there=E2=80=99s interest, I could potentially see throwing some = engineering effort into this. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?046580B0-BF8E-4A83-B1BB-28C632B1B9B5>