Feature-Request

[GoogleCodeExporter]

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?

Original issue reported on code.google.com by gia07...@googlemail.com on 30 Dec 2010 at 10:50

[GoogleCodeExporter]

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.

Original comment by axk...@gmail.com on 30 Dec 2010 at 12:18

[GoogleCodeExporter]

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.

Original comment by gia07...@googlemail.com on 30 Dec 2010 at 2:38

[GoogleCodeExporter]

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.

Original comment by axk...@gmail.com on 2 Jan 2011 at 10:58

[GoogleCodeExporter]

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 comment by axk...@gmail.com on 7 Feb 2011 at 2:23

• Changed state: Wait

[GoogleCodeExporter]

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.

Original comment by flowe...@gmail.com on 10 Aug 2011 at 8:03

[GoogleCodeExporter]

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 comment by axk...@gmail.com on 11 Aug 2011 at 7:19

• Changed state: Done