Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make inotify events configurable #16

Closed
GoogleCodeExporter opened this issue Jun 5, 2015 · 7 comments
Closed

Make inotify events configurable #16

GoogleCodeExporter opened this issue Jun 5, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

Lsyncd does not allow the user to configure the triggering inotify events.
Instead lsyncd registers the following events ATTRIB, CLOSE_WRITE, CREATE,
DELETE, DELETE_SELF, MOVED_FROM, MOVED_TO, DONT_FOLLOW, ONLYDIR. In some
use cases this will result in unnecessary sync operations which is in
particular painful if the network bandwidth between source and destination
is an issue.

Given an remote application which puts files in the lsyncd source by
creating a temporary file (CREATE), copy the data (CLOSE_WRITE), moving the
temporary file to the final filename (MOVE_FROM, MOVE_TO). This application
behavior is common because the final move command is an atomic operations
which ensures that only completely transmitted files are available within
the data source. In this use case lsyncd will trigger 4 rsync operations
and the data file will be transmitted twice.

The attached patch introduces the new configuration node <inotify> which
may be configured in the global <settings> section or on a <directory>
basis. If no <inotify> node is configured then the previously described
default event list is used.

Sample configuration:

<lsyncd version="1">
    <directory>
        <inotify>
            <event id="MOVED_TO"/>
            <event id="DELETE"/>
        </inotify>
        <source path="/var/data"/>
        <target path="destination_host::dest"/>
    </directory>    
</lsyncd>

Original issue reported on code.google.com by goo...@stephan.herrnkind.eu on 10 Apr 2010 at 10:37

Attachments:

@GoogleCodeExporter
Copy link
Author

Nice update.

Original comment by cesar.go...@gmail.com on 22 Apr 2010 at 5:39

@GoogleCodeExporter
Copy link
Author

Excellent point, thank you.

Original comment by dughu...@gmail.com on 26 May 2010 at 8:43

@GoogleCodeExporter
Copy link
Author

I dunno if this is really needed with 1.33 aggregating calls eitherway. More 
configurability is always nice yes, but the usecase described should be handled 
already (in a general way)

Original comment by axk...@gmail.com on 11 Jul 2010 at 8:18

  • Changed state: Wait

@GoogleCodeExporter
Copy link
Author

The usecase described is only handled by the new aggregation feature if the
transmission of the data file to the lsyncd directory takes no longer than the
configured 'delay' seconds. So the delay must be set to a value which covers
the average transmission time plus a security margin. Given a large file and a
low bandwidth connection, let's say 1MB and 10KB/s, the delay must be set to a
value greater than 100s. If the file size is arbitrary or if the file size
differs between each observed subdirectory a good configuration is not easy to
archive.

The attached patches add the <inotify> configuration feature to version 1.34.

Original comment by goo...@stephan.herrnkind.eu on 16 Jul 2010 at 7:08

Attachments:

@GoogleCodeExporter
Copy link
Author

Original comment by axk...@gmail.com on 18 Jul 2010 at 9:31

  • Changed state: New

@GoogleCodeExporter
Copy link
Author

Yes, it cant hurt to make this thing generally more configurable than fixing 
settings. Will integrate.

Original comment by axk...@gmail.com on 18 Jul 2010 at 9:32

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

Integrated in 1.37. Thanks sh2342.

Original comment by axk...@gmail.com on 5 Aug 2010 at 1:14

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant