Как интерпретировать и исправить ошибку ввода / вывода в Linux?
Я запускаю ежедневное резервное копирование с rsync. Начиная несколько дней назад, один из файлов выдавал эту ошибку во время резервного копирования:
rsync: read errors mapping "/home/folder/file.ext": Input/output error (5) WARNING: /home/folder/file.ext failed verification -- update discarded (will try again). Какой лучший курс действий? Это просто битый файл? Или что-то не так с жестким диском в расположении файла? Должен ли я просто удалить его и скопировать одну из резервных копий в папку файла? Или есть что-то еще / больше, что я должен сделать?
3 ответа 3
read errors mapping . Input/output error (5) указывает на невозможность rsync для чтения или записи файла. Наиболее вероятные причины этой ошибки — дефекты диска, либо в SRC, либо в каталоге TGT. Другие возможности, однако, включают недостаточные разрешения, блокировку файлов антивирусными программами и, maybe другие причины.
Первый шаг к диагностике — попытаться скопировать файлы вручную. Это может сработать, если, например, источником ошибки был дефект диска в каталоге TGT; повторив операцию позднее, вы запишете в другой раздел диска, и проблема может испариться.
Кроме того, вы можете обнаружить, что не можете получить доступ к файлу в каталоге SRC. В этом случае я предлагаю вам использовать любую из утилит проверки диска, доступных вашему дистрибутиву.
Недостаточные привилегии, антивирус, легче диагностировать.
Наконец, если у вас в каталоге SRC поврежденный сектор, вы можете исключить его из будущих запусков rsync с помощью
rsync -av --exclude='/home/my_name/directory_with_corrupt_files/*' У меня была похожая проблема, у меня было устройство с предохранителем через USB, которое часто отключалось, вызывая ошибки ввода-вывода. Моя резервная копия не может быть завершена, потому что ошибки ввода-вывода начнутся на полпути в rsync, и, несмотря на многократное выполнение rsync, в какой-то момент синхронизация не продвинется дальше обновления существующих файлов.
Мое решение было использовать
вариант. Таким образом, я мог запустить синхронизацию в цикле, пока не увидел состояние выхода 0.
Конечно, в этом случае я не заботился об обновлениях существующих файлов.
У меня есть 2 внешних диска, которые я синхронизирую, используя rsync . Я регулярно выполняю эту задачу на одной из двух машин и часто для удобства переключаюсь с одной на другую. У меня есть 4 машины с Debian 9, и я использую эти диски на каждой из них.
Этим утром я использовал следующее:
rsync -ahv --delete drive-x drive-y и был удивлен, получив несколько сотен сообщений об ошибках.
в основном: rsync: readlink_stat. failed: Input/output error (5)
также: rsync: rsync: recv_generator: mkdir . failed: Read-only file system (30)
В процессе выяснения того, что произошло, я дважды перемонтировал диски, перезагрузил их, запустил rsync без —delete и в основном мои обычные попытки исправить то, что надежно работало в течение длительного времени. Даже думал об установке rsync снова. Прежде чем я это сделал, я решил rsync 2 дисков на другой машине, которую я запускаю в автономном режиме. rsync работал так, как должен.
Прочитав материал, размещенный здесь, я установил clamav , обновил подписи и отсканировал мой домашний каталог. Я регулярно использую это на другой машине. Я нашел 1 и только 1 PUA и удалил его. Я всегда удаляю PUA. Затем я перемонтировал два диска на этом компьютере и добавил разные тестовые файлы и папки на каждый диск.
Я запустил rsync -ahv —delete drive_x drive_y и все работало нормально.
Ошибка ввода вывода hdd
Доброго времени суток! Есть жесткий диск на 3тб, который стоял в каком-то NAS от D-Link. Диск работал, потом попробовали воткнуть в Synology, который при попытке форматнуть диск выдал ошибку. Теперь диск форматнуть не получается. Gparted не видит таблицу разделов. При попытке определить диск выдает:
Ошибка синхронизации или закрытия файлов /dev/sdb: Ошибка ввода/вывода
sudo fdisk -l /dev/sdb fdisk: невозможно открыть /dev/sdb: Ошибка ввода/выводаsudo badblocks -s /dev/sdb > /home/yazov/badsudo dd if=/dev/zero of=/dev/sdb bs=512 count=1Есть какие-нибудь идеи или это труп? Диск относительно свежий, год ему. Данные мне не нужны, а вот диск — напротив.
Найди в dmesg записи про этот диск. Если они затёрлись надо будет передёрнуть диск.
2745.611235 blk_update_request: I/O error, dev sdb, sector 0
2746.867183 sd 5:0:0:0: sdb tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
2746.867187 sd 5:0:0:0: sdb tag#14 Sense Key : Illegal Request current descriptor
2746.867190 sd 5:0:0:0: sdb tag#14 Add. Sense: Unaligned write command
2746.867194 sd 5:0:0:0: sdb tag#14 CDB: Write(16) 8a 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00
2746.867197 blk_update_request: I/O error, dev sdb, sector 0 2746.867200 Buffer I/O error on dev sdb, logical block 0, lost async page write
2746.915282 sd 5:0:0:0: sdb tag#8 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
2832.256871 sd 5:0:0:0: sdb tag#30 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
2832.256882 blk_update_request: I/O error, dev sdb, sector 0
2832.256885 Buffer I/O error on dev sdb, logical block 0, async page read
2832.304933 sd 5:0:0:0: sdb tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
2832.304936 sd 5:0:0:0: sdb tag#5 Sense Key : Illegal Request current descriptor
2832.304939 sd 5:0:0:0: sdb tag#5 Add. Sense: Unaligned write command
2832.304943 sd 5:0:0:0: sdb tag#5 CDB: Read(16) 88 00 00 00 00 00 00 00 00 18 00 00 00 08 00 00
2832.304945 blk_update_request: I/O error, dev sdb, sector 24
2832.304948 Buffer I/O error on dev sdb, logical block 3, async page read
2832.400881 sdb: unable to read partition table
cp: не удалось расширить «/media/tmp_win_ntfs/sleepdogX360club.iso»: Ошибка ввода/вывода
Если после такой ошибки попробовать скопировать файл под другим именем, чтобы эта частична копия осталась и занимала место, что будет? Возможно, что ntfs не прочеканная и свободное место не соответствует кол-ву свободных блоков.
[704021.499516] Sense Key : 0x3 [current] [descriptor]
[704021.499521] Descriptor sense data with sense descriptors (in hex):
[704021.499523] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[704021.499533] 29 7e 8e 40
[704021.499537] sd 0:0:0:0: [sda]
[704021.499539] ASC=0x11 ASCQ=0x4
[704021.499541] sd 0:0:0:0: [sda] CDB:
[704021.499543] cdb[0]=0x28: 28 00 29 7e 8e 40 00 00 08 00
[704021.499552] end_request: I/O error, dev sda, sector 696159808
[704021.499579] ata1: EH complete
скопировал файл до удаления — его размер всегда 2.4 гб, head и tail показывают то, что это тот самый iso
Что ещё можно сделать? Форматнуть ntfs раздел на внешнем винте?
Но почему размер копируемого файла всегда одинаковый?
dev sda это что? То куда копируется или то, откуда копируется?
винт сыпится, ФС ни при чем.
алсо, вангую, что «расширение» это надмозговый перевод какого-то сообщения об ошибке, где присутствует слово «extent»
т.е. не удалось выделить новых экстентов под файло, как-то так.
ну а причина у тебя в дмесге.
/dev/sda — винт на ноуте, с которого
/dev/sdb — внешний, куда копируем
Ну, дак если ошибка ввода-вывода на /dev/sda, значит винт на ноуте посыпался, и имнно на отметке 2,4 Гбайт в этом файле битый сектор. Для проверки попробуйте просто скопировать этот файл на тот же раздел, где он лежит, а не на внешний винт.
mky ★★★★★ ( 31.10.14 15:17:02 MSK )
Последнее исправление: mky 31.10.14 15:17:22 MSK (всего исправлений: 1)
О, ошибка повторилась
На этот раз с другим файлом, который копирую на другой раздел этого же винта
С ext4 на примонтированный раздел винды (не помню, fat или ntfs)
/dev/sda1 on /mnt/win type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
cp: ошибка чтения «Mortal Kombat Trilogy (v1.1).7z»: Ошибка ввода/вывода
cp: не удалось расширить «/mnt/win/games_linux/psxr/Mortal Kombat Trilogy (v1.1).7z»: Ой всё, ошибка ввода/вывода
причем маленькие файлы копирует сотнями, а если файл больше 200 мб — то mc виснет или пишет ошибку и предлагает удалить то, что уже скопировалось
и при копировании на внешний fat та же ошибка получается проблема либо с арчем, либо с винтом ноута(
sergey-novikov ★★★ ( 31.10.14 17:49:51 MSK )
Последнее исправление: sergey-novikov 31.10.14 17:52:09 MSK (всего исправлений: 1)
Запустите ″badblocks /dev/sda″ — просто прочитать все блоки подряд, потом ещё посмотрите SMART, раз sda не внешний винт, SMART должен быть доступен и, наверное, там будет много ″Current Pending Sector″.
мда, почекал на бэды — на 30% винта нашло 60 штук
видимо это уже неизлечимо и надо менять винт?
Думаю, что, да, нужно менять. Бывает, конечно, что bad’ы возникают из-за удара, отдельная область, диск её потом ремапнет и ещё долго живёт. Но, если они «размазаны», то это, скорее всего, признак износа, и их будет всё больше и больше.
sudo badblocks /dev/sda
66049448
66049449
66049450
66049451
125438540
125438541
125438542
125438543
125438544
125438545
125438546
125438547
^C