X-Git-Url: http://git.tuebingen.mpg.de/?a=blobdiff_plain;f=dss.suite;h=d4926c3117ab214461d44b359beb02e77bfcd9f5;hb=faed24aec8859d232fe3c0da415265e0de099ce4;hp=e7473cb6d2f4ab619c753262664ff5c377ed21c6;hpb=3025388040c1521121255e5ae7ceabdcb1b1e421;p=dss.git

diff --git a/dss.suite b/dss.suite
index e7473cb..d4926c3 100644
--- a/dss.suite
+++ b/dss.suite
@@ -109,6 +109,29 @@ caption = Subcommands
 			Set this if the user that runs dss is different from the user on the
 			remote host.
 		[/help]
+	[option checksum]
+		summary = run rsync with --checksum occasionally
+		typestr = permille
+		arg_info = required_arg
+		arg_type = uint32
+		default_val = 0
+		[help]
+			If a file on the backup becomes corrupt in a way that file size
+			and modification time still match the original file, rsync will not
+			consider the file for transfer ("quick check"). Hence the corruption
+			stays on the backup until the file is modified on the source.
+			The --checksum option of rsync disables the quick check and compares
+			the contents of each file, fixing such corruptions. Since computing
+			the checksums adds a significant slowdown due to a lot of disk I/O,
+			the option is not enabled by default.
+
+			The argument to the --checksum option of dss is a number between 0
+			and 1000, inclusively, which determines the probability of adding
+			--checksum to the rsync options each time a snapshot is created. The
+			default value zero means to never add the option. The value 100 will
+			create every tenth snapshot (on average) using checksums, and the
+			value 1000 will always pass --checksum to rsync.
+		[/help]
 	[option rsync-option]
 		short_opt = O
 		summary = further rsync options
@@ -452,6 +475,27 @@ caption = Subcommands
 
 			Sending SIGHUP causes the running dss process to reload its config file.
 		[/help]
+	[option wait]
+		short_opt = w
+		summary = wait until the signalled process has terminated
+		[help]
+			This option is handy for system shutdown scripts which would like
+			to terminate the dss daemon process.
+
+			Without --wait the dss process which executes the kill subcommand
+			exits right after the kill(2) system call returns. At this point the
+			signalled process might still be alive (even if SIGKILL was sent).
+			If --wait is given, the process waits until the signalled process
+			has terminated or the timeout expires.
+
+			If --wait is not given, the kill subcommand exits successfully if
+			and only if the signal was sent (i.e., if there exists another dss
+			process to receive the signal). With --wait it exits successfully
+			if, additionally, the signalled process has terminated before the
+			timeout expires.
+
+			It makes only sense to use the option for signals which terminate dss.
+		[/help]
 
 [section copyright]
 	Written by Andre Noll