Linux ошибка ввода вывода на флешке
Обновлено: 07.07.2024
Файловые системы отвечают за организацию хранения и восстановления данных. Так или иначе, со временем файловая система может быть повреждена, и некоторые её части могут оказаться недоступными. Если ваша файловая система обнаруживает такую несогласованность, рекомендуется проверить её целостность.
Это можно сделать с помощью системной утилиты fsck (проверка целостности файловой системы). Эта проверка может выполняться автоматически во время загрузки или запускаться вручную.
Когда использовать fsck в Linux
Есть разные сценарии, когда вы захотите запустить fsck. Вот несколько примеров:
- Система не загружается.
- Файлы в системе повреждаются (часто вы можете увидеть ошибку ввода/вывода).
- Подключенный диск (включая флешки/SD-карты) не работает должным образом.
Опции программы fsck
Команду fsck необходимо запускать с привилегиями суперпользователя или root. Вы можете использовать её с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:
Как запустить fsck для исправления ошибок файловой системы Linux
Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для целей этой статьи я буду использовать свой второй диск /dev/sda, смонтированный в /mnt/disk_d.
Вот что произойдёт, если я попытаюсь запустить fsck, когда раздел смонтирован.
Если диск не только смонтирован, но и используется (например, диск, смонтированный в корневую файловую систему), то ошибка будет «/dev/nvme0n1 is in use».
Чтобы избежать этого, отключите раздел с помощью следующей команды (замените имя диска на ваше):
Тогда можно будет безопасно запускать fsck.
Понимание кодов выхода fsck
После запуска fsck он вернёт код выхода. Эти коды можно увидеть в руководстве по fsck, запустив:
Описание кодов выхода fsck:
Флаг -y означает автоматически отвечать «да» на любые запросы от fsck для исправления ошибки.
Точно так же вы можете запустить то же самое во всех файловых системах (с пропуском корневой файловой системы):
Как запустить fsck на корневом разделе Linux
В некоторых случаях вам может потребоваться запустить fsck в корневом разделе вашей системы. Поскольку вы не можете запустить fsck, пока раздел смонтирован, вы можете попробовать один из следующих вариантов:
- Принудительно использовать fsck при загрузке системы
- Запустите fsck в режиме восстановления
Мы рассмотрим обе ситуации.
Как принудительно проверить диск с помощью fsck при загрузке системы
Это относительно легко выполнить, единственное, что вам нужно сделать, это создать файл с именем forcefsck в корневом разделе вашей системы. Используйте следующую команду:
Затем вы можете просто принудительно перезагрузить или запланировать перезагрузку системы. Во время следующей загрузки будет выполнена проверка диска командой fsck. Если время простоя критично, рекомендуется тщательно его спланировать, поскольку, если в вашей системе много используемых inode, выполнение fsck может занять дополнительное время.
После загрузки системы проверьте, существует ли ещё файл:
Если это так, вы можете удалить его, чтобы избежать появления fsck при каждой загрузке системы.
Как запустить fsck в режиме восстановления
Для запуска fsck в режиме восстановления требуется ещё несколько шагов. Сначала подготовьте вашу систему к перезагрузке. Остановите все критически важные службы, такие как MySQL/MariaDB и т. д., а затем введите.
Во время загрузки удерживайте нажатой клавишу Shift, чтобы отобразилось меню grub. Выберите Advanced options («Дополнительные параметры»).
Затем выберите Recovery mode («Режим восстановления»).
В следующем меню выберите «fsck».
Вас спросят, хотите ли вы перемонтировать / файловую систему. Выберите Yes («да»).
Вы должны увидеть нечто подобное.
Затем вы можете вернуться к нормальной загрузке, выбрав Resume («Возобновить»).
Заключение
В этом руководстве вы узнали, как использовать fsck и выполнять проверки согласованности в разных файловых системах Linux. Если у вас есть какие-либо вопросы о fsck, не стесняйтесь задавать их в разделе комментариев ниже.
Я хочу перечислить и удалить содержимое каталога на съемном жестком диске. Но я испытал «Ошибка ввода / вывода»:
Мне было интересно, в чем проблема?
Как я могу восстановить или удалить каталог pic и все его содержимое?
Моя ОС - Ubuntu 12.04, а съемный жесткий диск имеет файловую систему ntfs. Другие каталоги, не содержащие или не находящиеся pic на съемном жестком диске, работают нормально.
Последняя часть вывода dmesg после того, как я попытался перечислить содержимое каталога:
Ошибка ввода-вывода может быть аппаратной проблемой (повреждение оперативной памяти или жесткого диска). Это также может означать повреждение файловой системы или ошибку драйвера; так как это NTFS, я не исключаю этого.Ошибки ввода / вывода при попытках доступа к файловой системе обычно означают аппаратные проблемы.
Введите dmesg и проверьте последние несколько строк вывода. Если диск или подключение к нему не удается, это будет отмечено там.
РЕДАКТИРОВАТЬ Вы монтируете его через ntfs или ntfs-3g ? Насколько я помню, устаревший ntfs драйвер не имел поддержки стабильной записи и был в основном заброшен, когда оказалось, что ntfs-3g он значительно более стабилен и безопасен.
Я подключаю съемный жесткий диск к своей Ubuntu 12.04, и он автоматически монтируется. Так я думаю ntfs-3g ? Не " угадай ". Проверьте - вы можете увидеть, как все монтируется, набрав mount команду и глядя на вывод. (1) Я добавил последнюю часть вывода dmesg после того, как попытался составить список содержимого каталога. Я не знаю, как это помогает. (2) Я не могу увидеть, смонтирован ли он с помощью nfts-3g или ntfs, посмотрев на вывод mount : /dev/sdb1 on /media/removable_drive type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) fuseblk означает, что он использует метод fuser файловая система в пользовательском пространстве, что и ntfs-3g используется. Так что ты хорош в этом отношении.Как утверждает Садхур, это, вероятно, вызвано аппаратными проблемами на диске, и dmesg выходной файл - правильное место, чтобы проверить это.
Вы можете выполнить сканирование поверхности вашего диска из Linux /sbin/badblocks /dev/sda .
Проверьте страницу руководства для более тщательного тестирования основных исправлений (перемещение блоков). Все это не зависит от файловой системы, поэтому является безопасным даже для файловой системы NTFS, поскольку работает на уровне «поверхности диска».
Я лично сделал это для запуска ежемесячно от cron. Конечно, вам нужно проверить, получаете ли вы письма cron в своем почтовом ящике (что по умолчанию часто не так). Эти письма заканчиваются /var/mail/$USER или похожи.
Я создал /etc/cron.d/badblocks :
Спасибо! Для запуска команды, которую вы предложили, это /sbin/badblocks /media/removable_drive в моем случае? Нет. Согласно выводу dmesg вы должны использовать sdb: /sbin/badblocks /dev/sdb или sdc. Я действительно не могу понять, что случилось / вы сделали dmesg Вы можете найти свой /dev/sdВаша файловая система повреждена, для томов NTFS вы должны запустить систему chkdsk под Windows, но восстановить ее практически невозможно. Иногда вам может понадобиться отформатировать диск.
Спасибо! Мои другие каталоги в порядке. Могу ли я не отформатировать весь диск, просто освободить место в каталоге? @ Тим, тебе пришлось скопировать все остальное, отформатировать и скопировать их обратно . я не знаю, можно ли удалить один узел . не знаком со структурой NTFS Перед форматированием попробуйте badblocks комманду в Linux.Решение, которое работает для меня, - понизить ntfs-3g версию с выпуска 2014 года до выпуска 2012 года. Это должно решить вашу проблему с доступом к разделу NTFS. В долгосрочной перспективе это не решение, потому что в конечном итоге вам потребуется запустить последнюю версию.
Хорошо, это хорошо знать. Таким образом, в основном существует окно между 2012 и началом 2016 года, в течение которого привод просто не работал.Я просто хотел добавить свое решение в эту ветку для блага других - я выполнил некоторую работу в своей системе, когда у меня вышел из строя источник питания - я, должно быть, переподключил кабели SATA в неправильном порядке, так как когда я их переключал, все работало снова - в любом случае, не знаю, почему загрузочный диск должен находиться на определенном порте SATA, может быть ответом для кого-то другого.
Никто не упомянул, что делать, если инструменты Linux не работают и доступен только Mac, но не Windows.
Может быть исправлено в OS X с Paragon NTFS
В моем случае gparted сказали пойти найти ПК с Windows, который нигде не было найдено. Но рядом был Mac, для которого доступно это замечательное программное обеспечение. Установил пробную версию, выполнил проверку , затем чинил - и вуаля!
У меня был случай на macos, когда такая ошибка была вызвана использованием sshfs (вроде бы) в сборке инструментария. Помогла установка osxfuse & sshfs через brew.Я просто хотел поделиться своим опытом: во FreeBSD 10.3 я подключил свой внешний жесткий диск с
Внутри жесткого диска я mkdir создал папку, а затем переместил в нее несколько файлов, конечно, с помощью mv команды. Наконец я выполнил следующую команду:
Я не смог избавиться от Jeff каталога на машине с Linux, поэтому я использовал машину с FreeBSD и снова смонтировал жесткий диск на FreeBSD. Но ls , cd и rm команды на FreeBSD генерировать то же самое Input/output error . Похоже, в ntfs-3g пакете FreeBSD была ошибка .
ОБНОВИТЬ
Я перенес все свои данные с внешнего жесткого диска на компьютер с Linux, конечно, поврежденный файл Jeff не мог быть перемещен из-за ошибки ввода-вывода. Затем я переформатировал внешний жесткий диск с обнулением тома и проверкой сбойного сектора следующим образом:
А затем переместил все данные обратно на внешний том. Таким образом, я потерял поврежденный файл с именем Jeff , однако мой внешний жесткий диск очищен от любых ошибок ввода-вывода.
Я объявил, что когда я пытаюсь получить доступ к диску, на котором возникла эта ошибка, он пытался записать последние скопированные файлы, которые были перезаписаны в последний файл, а затем попытка доступа не удалась, потому что уже записанная запись не совпадает с последними скопированными элементами, поэтому происходит сбой. Самый здоровый способ спасти диск - удалить последний элемент или элементы, скопированные в Windows.
Выполнение fsck.fat /dev/block/mmcblk0p1 , устройство моей неисправной SD-карты, я получаю это:
Это означает, что файлы постоянно нечитабельны?
Выполнение fsck возвращает следующее:
ddrescue ничего не может сохранить. Вывод df :
Обновление: ситуация становится более странной. На моей машине Windows кажется, что вся SD-карта читаема. Однако копирование файлов является чрезвычайно медленным со случайными возвратами к регулярной скорости передачи. Мне удалось скопировать файлы, что я был главным образом после (фотографии, сделанные после моего последнего резервного копирования), но после определенного момента Windows Explorer не продолжится в копировании, неважно, сколько времени я ожидал.
Я вернулся к Ubuntu и к моему удивлению, fsck.fat на самом деле работал успешно. Выполнение его несколько раз дает некоторую комбинацию следующего: Has a large number of bad entries. (128/133) , Free cluster summary wrong (42991 vs. really 43267) , Orphaned long file name part , Contains a free cluster (144584). Assuming EOF. , Start does point to root directory. Deleting dir. ddrescue работает хорошо прямо сейчас, таким образом, я позволю ему продолжать бежать на данный момент.
Любопытно это походит на спящий режим и неспящий режим, или приостановку и возобновление, и ожидание могло бы позволить Ubuntu ddrescue спасите изрядное количество.
1 ответ
Как правило, ошибки ввода-вывода означают, что система столкнулась с неисправимой аппаратной ошибкой. Любые файлы на объеме ошибочного луга ввода-вывода нужно считать потерянными.
После этих слов восстановление данных все еще возможно (хотя немного трудно). К счастью, существует несколько утилит, которые могут выручить Вас:
- dd
DD (шутливоизвестный как РазрушительДанных) является встроенной утилитой большинства - если не все - современные системы Linux. В худшем случае можно попытаться использовать dd сделать изображение Вашего флеш-накопителя, который мог бы позволить еще некоторым усовершенствованным средствам восстановления (или для файлового менеджера) работать успешно. Убедитесь, что Вы указываете право команд, иначе Вы изучите точно, почему это известно как Разрушитель Данных.
Ddrescue является специальной утилитой, которая может использоваться для чтения как можно больше из дефектных объемов. Если бы Вы выполняете это, я настоятельно рекомендовал бы, чтобы Вы записали в файл изображения и отделались от этого для любых других операций восстановления (если кто-либо даже возможен).
В то время как его имя подразумевает, что это только для фотографий, photorec может часто использоваться для восстановления намного больше с диска, если дано шанса. Это, вероятно, не сможет восстановить данные из любых erroring секторов Вашего устройства, но это смогло спасать некоторые вещи.
Если восстановление невозможно, Вы можете восстанавливать карту при помощи dd и другие утилиты для перезаписи всего диска с нулями. Это, как было известно, (в некоторых редких случаях) на самом деле возвращало диск жить (хотя, теряя содержание диска в прогрессе). Однако это - почти всегда лучшая идея просто получить новый диск. После того как диск перестал работать, он теряет любое подобие доверия, которое он когда-либо имел.
Опишем окружение в котором возникла ошибка ввода/вывода:
- ОС: Linux совместно с Windows
- HDD: два диска, на одном Windows XP (далее ДИСК 1 ), на другом Linux Debian 7.x (далее ДИСК 2 )
Каждый диск разбит на два раздела, - на диске с Windows XP два раздела с файловой системой NTFS, на втором диске с Linux Debian 7.x один раздел EXT4, на котором и установлен Linux, а на втором собственно NTFS. Окружением для рабочего стола Linux было выбрано Xfce, файловый менеджер по умолчанию Thunar 1.2.3 (Thunar это быстрый и простой в использовании файловый менеджер для рабочего окружения Xfce.), текстовый редактор gedit.
Ошибка ввода/вывода появилась на ДИСК 2 в разделе с файловой системой NTFS, который монтировался вручную после входа в уч. запись Linux.
Когда именно появилась Ошибка ввода/вывода на NTFS разделе сказать сложно, но предположительно после очередного переключения между ОС. На ДИСК 2 были расположены совместно редактируемые файлы, - т.е. эти фалы (Test.txt один из них) были открыты в текстовом редакторе notepad++ под ОС Windows XP и в текстовом редакторе gedit под Linux Debian 7.x. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.
Не скажу, как и почему стала появляться Ошибка ввода/вывода, - возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:
Попытка открыть каталог " /media/SATA2/PROFILE/User/Рабочий стол " в Thunar:
Остальное содержимое каталога было не доступно для просмотра/редактирования
Попытка сохранить уже открытый в gedit текстовый файл Test.txt :
При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить " Test.txt ", но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:
Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):
Владелец и права на файл Test.txt не известны:
В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5 , предварительно отмонтировав его, - но проблема не решилась.
В среде Linux на ДИСК 2 были созданы текстовые файлы " Test_2.txt " и " Test_3.txt " и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать.
Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:
Увидев на экране Deleting index entry . я зразу же понял, что этих файлов нам уже не видать как своих ушей, - разумеется, так и есть.
Существует также ещё один способ монтирования NTFS с возможностью чтения/записи, - это Проект NTFS-3G, который по заявлениям является более функциональным и стабильным вариантом (также использующий FUSE) дающий более широкие возможности по созданию/изменению/удалению/перемещению файлов (исключая сжатые и зашифрованные файлы) в файловой системе NTFS. В тоже время тесты показывают, что NTFS-3G не оптимизирован для производительности, а разработчики заявляют, что это связано с обеспечением повышенной надёжности и, что производительность является второстепенной задачей.
Никто не застрахован от возникновения каких-то ошибок на разделах с файловой системой NTFS или же вовсе полного краха таких разделов с необходимостью полного форматирования. Поэтому, при использовании Linux лучше вовсе не использовать NTFS разделов, или же использовать их как можно реже.
Основные причины ошибок ввода/вывода
- Значит это всё масонский заговор дядюшки Билла. На буржуйских веб-ресурсах бродит информация о том, что стандарт NTFS меняется в каждой новой версии Windows, что вполне предсказуемо, включая сервис-паки и промежуточные патчи. При этом, разумеется, изменения не придаются общественной огласке, а следовательно нет возможности в полной мере обеспечить стабильную работу с NTFS в свободных ОС таких как Linux.
- Отмечено также, что на разделах NTFS возможно изменение уже существующих файлов с незначительным изменением их размера, но при создании новых файлов или существенного изменения уже существующих может вызвать проблемы и даже "запороть" весь раздел.
- Проблемы с отображением созданных в Linux на NTFS разделе файлов, а также проблемы с ошибками ввода/вывода, могут возникнуть если на ПК установлено несколько ОС (ака Мультизагрузка, Multi-boot), - Windows vs Linux. Пик ошибок ввода/вывода отмечен когда Windows была переведена в спящий режим, а после очередного включения запущен Linux из-под которого на NTFS разделе создавались/редактировались файлы. Другими словами если мы хотим из-под ОС Linux, в условиях мультизагрузки (Multi-boot), относительно безопасно создавать/редактировать файлы на NTFS разделах совместно используемых обеими ОС, то перед запуском ОС Linux мы должны выполнить полную перезагрузку или остановку ОС Windows, но не в коем случае не переводить Windows в спящий режим!
- SRT-кэширование (Smart Response Technology) - ещё одна "фича", которая может стать причиной невидимости из-под Windows на NTFS разделах файлов, которые создавались в Linux. Предположительно Linux не поддерживает SRT-кэширование (касается только SSD дисков), которое поддерживает Windows, а значит при создании из-под Linux-а файлов на SSD дисках с активным SRT-кэширование кэш не обновляется и после загрузки Windows файлов не обнаруживается. Предлагается отключить SRT-кэширование для SSD диска.
Тема использования NTFS в Linux является довольно актуальной, требует более подробного изучения и дополнительных экспериментов. О появлении новых багов, в ходе использования NTFS разделов в Linux, и, способов их решения, - будем дописывать в этой же статье.
Рекомендуемый контент
Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).
Примечание: описанные методы работают не только для USB-накопителей, но и для жестких дисков тоже.
Интересно: Как отформатировать защищенную от записи флешку. Читаем здесь.
Удаление бэд-блоков с USB-накопитель с помощью fsck
Простой способ починить флэш-накопитель (и вообще любой накопитель) – инструмент fsck. Он удаляет поврежденные сектора, или «бэд-блоки», из-за которых чаще всего и возникают проблемы с чтением. Чтобы удалить поврежденные сектора с флэшки, откройте терминальное окно и введите следующие команды.
Сначала нужно узнать метки дисков. Сделайте это, введя команду lsblk. Появится список всех подключенных накопителей.
Примечание: по команде lsblk появляется список всех дисков, не только USB-накопителей. Будьте внимательны, чтобы не перепутать флэшку с жестким диском.
Чтобы удалить бэд-блок, запустите команду fsck либо в отдельном разделе (например, /dev/sdc1), либо на всем диске (например, /dev/sdc). По окончании процесса ваша флэшка будет снова полностью работоспособна в Linux.
sudo fsck /dev/sdc1
Полная очистка
Иногда USB-накопитель совершенно не читается, и спасти что-то с него уже не получится. Все, что остается в этой ситуации – очистить все данные и начать сначала. Лучший инструмент для этого – dd.
Возьмите метку накопителя, которую вы нашли прежде командой lsblk, и дальше действуйте по предыдущему алгоритму (/dev/sdc1 – раздел, /dev/sdc – весь диск):
sudo dd if=/dev/zero of=/dev/sdc
Создание новой файловой системы
Очистка флэшки (или любого другого накопителя) делает все записанные данные на ней бесполезными. Это значит, что нужно создать новый раздел данных. Выберите желаемую файловую систему и введите соответствующую команду:
Fat32
sudo mkfs.msdos -f 32 /dev/sdc1
Ext4
sudo mkfs.ext4 -f /dev/sdc1
NTFS
sudo mkfs.ntfs -f /dev/sdc1
Заключение
USB-флэшки – полезные девайсы. С ними легко переносить данные с одного компьютера на другой вне зависимости от установленной ОС. Вот почему важно знать, что делать, если флэшка вдруг стала недоступной. К счастью у Linux есть мощные инструменты, способные легко «вылечить» флэш-накопитель.
Читайте также: