Feature-Request

[axkibe]

Originally filed by gia07...@gmail.com on 2010-12-30T10:50:12

I'd like to see lsyncd supporting fanotify, since we have lots of files in many different directories and cannot use inotify.

How long do think would it take to implment fanotify into lsyncd? I'm well aware of the "move"-problem, but don't care.

Maybe we can speed things up a little bit by helping you to test or pay a reward?

[axkibe]

Updated by axk...@gmail.com on 2010-12-30T12:18:38

Thank you, but how can you not care about the "move"-problem? Rename events change the filesystem without possibility to transfer them when watching with fanotify.

[axkibe]

Updated by gia07...@gmail.com on 2010-12-30T14:38:49

i'm planning a livebackup and would do a normal Rsync once a day to catch the moves. in this environment it is more crucial for me to have the data anywhere on the filesystem than have it in the right location.

[axkibe]

Updated by axk...@gmail.com on 2011-01-02T10:58:00

I'm currently studying the fs/i/fanotify implementation in Linux. I'd rather manage to get some patch into the kernel that allows root users to use inotify to register for mount point events like fanotify has. So far I realized fanotify is really much more tailored to malware software rather than indexers/backup utils like Lsyncd. It delivers an open filedescriptor with every event, very useful for these utils, but for Lsyncd not useful, and it starts to violate the Lsyncd principle to not interfere and reduce perfomance between application and kernel/disc.

If a future use of fanotify might be for a strict semaphore master-master syncing, where Lsyncd holds back an open() event until it notified other nodes to lock it. Or to refuse it, if the file is opened by other nodes.

[axkibe]

Updated by axk...@gmail.com on 2011-02-07T14:23:11

I currently don't have the focus to work on the kernels implemenation, sorry. Also I dont see myself adding a fanotify implementation that doesnt track moves. I know that for a few people like you, who know exactly what they are doing, and which limitations they can expect, fanotify would currently make sense nevertheless, but I cannot maintain this feature as well.

Lsyncd has some sources scratched for fanotify, and has its infrastructure modular enough to support multiple notifications mechanism as can be seen with the support for fsevent 10.5. So if you need it, you can code it :-)

Original ticket set status to Wait (we converted to open)

[axkibe]

Updated by flowe...@gmail.com on 2011-08-10T20:03:00

Hi,

I'm working backwards from the synchronization concept I want to achieve and have wound up here. I wonder if the functionality from fschange is sufficient for lsyncd's needs?

http://stefan.buettcher.org/cs/fschange/index.html

I know it's not in linus's kernel, and the patches are surely bit-rotted, but it looks like the party line is that inotify's ABI is permanently frozen, so that seems like a dead end.

[axkibe]

Updated by axk...@gmail.com on 2011-08-11T07:19:50

That work is pretty dated. Especially the Linux' event notification system has been completly reworked since then in the light of fanoity. So I don't suppose that patches can fit even close. Fanotify is btw. currently not usable for Lsyncd, as it misses move events.

The notification mechanisms of Linux are still a mess. You got inotify, filename/tag based writter for user interfaces, and you got fanotify, filedescriptor based, written for malware protection. Non fits well for indexers and watchers like Lsyncd also is. I hope the next notification system that comes around will finally merge the functionality of inotify and fanotify.

Lsyncd 2.x is written pretty modular regarding notification systems, in the source you'll see it supports inotify as well fsevents on OSX. It should be no rocket science to add another protocol here. However, developing a better notification system for the kernel probably is.

Original ticket set status to Done (we converted to open)