Необъясненное разъединение rsync

Файлы редко повреждаются сами по себе. Как правило, повреждение файловой системы является результатом основной аппаратной ошибки. Сообщение

mount: cannot remount block device /dev/sda3 read-write, is write-protected

указывает, что ядро обнаружило аппаратную ошибку, и для предотвращения дальнейшего повреждения данных оно помечает базовое устройство только для чтения. Создание файловой системы только для чтения было побочным эффектом этого.

Невозможно переключить файловую систему обратно в режим «чтение-запись», поскольку блочное устройство по-прежнему доступно только для чтения. Вы можете сделать блок устройством для чтения-записи с помощью blockdev --setrw/dev/sda3 , а затем повторно подключить файловую систему для чтения-записи. Однако это плохая идея , как и перезагрузка и продолжение использования диска. Не игнорируйте эту ошибку: оборудование неисправно, и данные будут повреждаться все больше и больше.

Проверьте журналы ядра на наличие ошибок. Вы должны видеть шквал сообщений журнала. Журналы ядра часто хранятся в /var/log/kern.log , но расположение зависит от дистрибутива и конфигурации системы, поэтому проверьте документацию дистрибутива. Можно вызвать команду dmesg для печати журналов ядра, но только для текущего сеанса необходимо просмотреть файлы журнала для сообщений, полученных до последней перезагрузки.

Распространенными причинами отказа диска являются отказ фактического диска, свободный кабель или отказ ОЗУ. Запустите smartctl -a/dev/sda для просмотра диагностики диска. Если это не указывает на сбой, выполните команду memtest86 + для проверки оперативной памяти.

cat < & 3 делает то, что он должен делать, а именно считывает из файла, пока он не достигнет конца файла. Когда вы вызываете его, позиция файла в дескрипторе файла находится в том месте, где вы в последний раз оставили его, а именно в конце файла. (Есть один файл позиции, не отдельные для чтения и для записи.)

cat/proc/$ $/fd/3 не делает то же самое, что cat < & 3 : он открывает один и тот же файл на другом дескрипторе. Поскольку каждый дескриптор файла имеет собственную позицию, а при открытии файла для чтения позиция устанавливается равной 0, эта команда печатает весь файл и не влияет на сценарий.

Если вы хотите прочитать написанное, необходимо либо открыть файл заново, либо перемотать дескриптор файла (т. е. установить его положение на 0). Нет встроенного способа сделать ни в оболочке POSIX, ни в большинстве реализаций sh ( есть один в ksh93 ). Существует только одна утилита, которая может искать: dd , но она может искать только вперед. (Есть другие утилиты, которые могут пропустить вперед, но это не помогает.)

Я думаю, что единственное портативное решение - запомнить имя файла и открыть его столько раз, сколько необходимо. Обратите внимание, что если файл не является обычным файлом, поиск в обратном направлении может быть невозможен.

Возможно, сервер возвращает сообщение @ ERROR , но клиент вместо этого неправильно сообщает об этом как о преждевременном EOF.

Первым шагом является определение основной ошибки. Я предлагаю вам запустить rsync с более простыми флагами, чтобы увидеть, работает ли он. Возможно, rsync не может загрузить libz , но он не замечает, пока не придет время что-то сжать.

Второй шаг состоит в том, чтобы клиент на стороне Yosemite рассказал вам что-то о 8 байтах, которые он получил. Если добавление достаточного количества флагов -v не делает этого, я предлагаю создать новый rsync (например, используя Homebrew и homebrew/dups keg). Это может сказать вам что-то полезное, что относительно старая rsync в запасе OSX не делает.

Если вы не возражаете против его настройки, вы можете настроить демон rsync на компьютере Yosemite, использовать ssh -R , чтобы включить пересылку порта обратно к нему, и запустить rsync вручную в оболочке веб-узла, чтобы он подключился к демону rsync на компьютере. Тогда его сообщение об ошибке будет ясно для просмотра.