будет ли у rysnc -z какое-либо преимущество сжатия, если входной файл уже распакован? У меня есть большой сжатый файл размером 100 ГБ для отправки по сети через серверы, и он постоянно терпел неудачу (разорванный канал) через разное время. Интересно, стоит ли мне использовать флаг -z?
3 ответа
Сжатие в пути уже сжатого файла обычно не стоит процессорного времени. Есть предостережения. В процессе сравнения двух файлов использование rsync со сжатием может ускорить сравнение хэшей данных.
Если вы хотите синхронизировать только сжатые версии больших файлов в более чем одной системе, то одним из мест, где можно посмотреть, будут определенные сборки gzip. В системе Ubuntu я получаю:
$ gzip -h Usage: gzip [OPTION]... [FILE]... Compress or uncompress FILEs (by default, compress FILES in-place). Mandatory arguments to long options are mandatory for short options too. -c, --stdout write on standard output, keep original files unchanged -d, --decompress decompress -f, --force force overwrite of output file and compress links -h, --help give this help -l, --list list compressed file contents -L, --license display software license -n, --no-name do not save or restore the original name and time stamp -N, --name save or restore the original name and time stamp -q, --quiet suppress all warnings -r, --recursive operate recursively on directories -S, --suffix=SUF use suffix SUF on compressed files -t, --test test compressed file integrity -v, --verbose verbose mode -V, --version display version number -1, --fast compress faster -9, --best compress better --rsyncable Make rsync-friendly archive With no FILE, or when FILE is -, read standard input. Report bugs to .
Заметьте, что опция --rsyncable
? Он избегает использования адаптивного сжатия, так что изменяются только небольшие фрагменты сжатого файла, когда в исходном файле есть только небольшое изменение. Остальная часть двоичных данных не изменяется, поэтому rsync не нужно будет повторно передавать все это. Страница man указывает, что эта опция не должна увеличивать размер сжатого файла более чем на 1% по сравнению с без использования этой опции, и что gunzip не будет знать разницу.
У меня есть файл sql 468 МБ, который я сжал до 57 МБ с параметром --rsyncable
. Я передаю этот файл в мою локальную систему. Затем я добавляю однострочный комментарий к исходному файлу sql в удаленной системе и повторно сжимаю его с помощью опции rsyncable.
$ rsync -avvz --progress -h fooboo:foo.sql.gz . opening connection using ssh fooboo rsync --server --sender -vvlogDtprz . foo.sql.gz receiving file list ... 1 file to consider delta-transmission enabled foo.sql.gz 59.64M 100% 43.22MB/s 0:00:01 (xfer#1, to-check=0/1) total: matches=7723 hash_hits=9468 false_alarms=0 data=22366 sent 54.12K bytes received 22.58K bytes 17.05K bytes/sec total size is 59.64M speedup is 777.59
Неплохо. Rsync должен был только передать небольшое количество нового сжатого файла.
rsync не сделает уже сжатый файл значительно меньше во время передачи.
Маловероятно, что ваши неудачные переводы будут исправлены добавлением флага -z. Я хотел бы предложить попытаться rsync файл (ы) без сжатия. rsync будет сжимать на лету. В этом случае у вас есть преимущество в том, что если исходный файл изменится, и вам потребуется снова выполнить rsync, будут переданы только измененные байты. Если вы измените сжатый файл, rsync, скорее всего, придется повторно передать его полностью. Смотрите здесь для более подробной информации:
Использование rsync -z
не будет иметь никакого преимущества перед rsync
при работе с файлом, который уже был сжат с использованием хорошего формата сжатия. Тем не менее, вы можете рассмотреть возможность разделения вашего сжатого файла на более мелкие части, чтобы вы могли передавать его с помощью rsync.
Вот руководство для Linux: http://www.techiecorner.com/107/how-to-split-large-file-into-several-smaller-files-linux/ А для Windows: http://www.online -tech-tips.com/computer-tips/how-to-split-a-large-file-into-multiple-smaller-pieces/