Ошибка ввода вывода в линукс

Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода. Неожиданная ошибка: Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода

Опишем окружение в котором возникла ошибка ввода/вывода:

• ОС: 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. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.

Иногда выполнялась перезагрузка ОС Linux Debian 7.x, но ОС Windows XP всегда переводилась в спящий режим, при этом после перезагрузки Linux Debian 7.x восстанавливалась сессия запущенных на момент перезагрузки/выключения программ, в том числе и редактора gedit с совместно редактируемым Test.txt. Потому как раздел NTFS с ДИСК 2 монтировался вручную, то после перезагрузки в gedit был открыт Test.txt с сообщением об ошибке доступа, но после ручного монтирования NTFS раздела редактор gedit предлагал обновить файл по причине его изменения.

Не скажу, как и почему стала появляться Ошибка ввода/вывода, — возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:

Попытка открыть каталог «/media/SATA2/PROFILE/User/Рабочий стол» в Thunar:

Не удалось открыть папку: «Рабочий стол».
 
Ошибка при получении информации о файле «/media/SATA2/PROFILE/User/Рабочий 
    стол/Test.txt»: Ошибка ввода/вывода.

Остальное содержимое каталога было не доступно для просмотра/редактирования

Попытка сохранить уже открытый в gedit текстовый файл Test.txt:

Не удалось сохранить файл /media/SATA2/PROFILE/Use…бочий стол/Test.txt.
 
Неожиданная ошибка: Ошибка при получении информации о файле «/media/SATA2/ 
    PROFILE/User/Рабочий стол/Test.txt»: Ошибка ввода/вывода

При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить «Test.txt«, но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:

Не удалось переименовать объект.
 
Не удалось переименовать объект «Безымянный документ» в «Test.txt»: Произошла 
    ошибка при переименовании файла: Ошибка ввода/вывода

Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):

Не удалось подключить «SATA2».
 
DBus error org.gtk.Private.RemoteVolumeMonitor.Failed: An operation is already 
    pending.

Владелец и права на файл Test.txt не известны:

root@linux:/media/SATA2/PROFILE/User/Рабочий стол# ls -la
ls: невозможно получить доступ к Test.txt: Ошибка ввода/вывода
итого 4415
drwx------ 1 User User   12288 Сен  2 22:21 .
drwx------ 1 User User    8192 Авг 18 07:48 ..
-rw------- 1 User User    1830 Сен  2 11:56 Test_2.txt
-rw------- 1 User User    3722 Сен  2 21:22 Test_3.txt
-????????? ? ?      ?            ?            ? Test.txt

В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5, предварительно отмонтировав его, — но проблема не решилась…

В среде Linux на ДИСК 2 были созданы текстовые файлы «Test_2.txt» и «Test_3.txt» и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать…

Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:

CHKDSK is verifyng indexes (stage 2 of 5)
 
    Deleting index entry .Trash-1000 in index $I30 of file 5
    Deleting index entry Test.txt in index $I30 of file 702196
    Deleting index entry Test_2.txt in index $I30 of file 702196
    Deleting index entry Test_3.txt in index $I30 of file 702196

Увидев на экране Deleting index entry … я зразу же понял, что этих файлов нам уже не видать как своих ушей, — разумеется, так и есть.

Вероятно (http://ru.wikipedia.org/wiki/NTFS#Linux) поддержка NTFS в Linux осуществляется при помощи ntfsmount (использующая FUSE), которая позволяет монтировать NTFS-разделы на запись, но с некоторыми ограничениями.

Существует также ещё один способ монтирования 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, и, способов их решения, — будем дописывать в этой же статье…

NTFS из под Linux, Ошибка ввода/вывода и невидимые данные

Есть диск на 500, с NTFS. Винды на нем как и в системе в общем нет. Стал чистить, возникли подозрения на плохое здоровье. Программа Disks(UDisks2.1.3) показывает 500 — 498 свободных и 0,4% занятых. Анализатор — Baobab говорит что на диске данных только от .Trash-1000 и там 13 метров. Хотя выдает ошибку ввода/вывода при просмотре содержимого, одного каталога(предполагаю что там и лежат лишнии данные которые я не могу увидеть). df -Th показывает 1.9 занятых, 466 размер и 464 доступных. 1% использовано.

Бэдов нет, ремапа нет. Диск здоров, по смарту тоже все нормально, кроме ошибок чтения — 1 ID, = 45.

Вопрос в том имеет ли смысл парится и искать проблему сейчас, или переделать диск, хочу в ext4, это второй диск не системный.

На системном тоже почти все вычистил, буду переделывать, весь диск тоже, ввиду старых проблем(две системы одна с артефактами от 12.04 обновлена до 19.04, вторая 14.04).

Думаю если на 500, форматнуть имеет ли смысл запускать все проверки снова, смарт расширенный и поиск бэдов, или сначала решить проблему в этой ситуации?

Источник

Linux и NTFS: Ошибка ввода/вывода

Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода. Неожиданная ошибка: Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода

Опишем окружение в котором возникла ошибка ввода/вывода:

• ОС: 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. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.

Иногда выполнялась перезагрузка ОС Linux Debian 7.x, но ОС Windows XP всегда переводилась в спящий режим, при этом после перезагрузки Linux Debian 7.x восстанавливалась сессия запущенных на момент перезагрузки/выключения программ, в том числе и редактора gedit с совместно редактируемым Test.txt . Потому как раздел NTFS с ДИСК 2 монтировался вручную, то после перезагрузки в gedit был открыт Test.txt с сообщением об ошибке доступа, но после ручного монтирования NTFS раздела редактор gedit предлагал обновить файл по причине его изменения.

Не скажу, как и почему стала появляться Ошибка ввода/вывода, — возможно 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 . я зразу же понял, что этих файлов нам уже не видать как своих ушей, — разумеется, так и есть.

Вероятно (http://ru.wikipedia.org/wiki/NTFS#Linux) поддержка NTFS в Linux осуществляется при помощи ntfsmount (использующая FUSE), которая позволяет монтировать NTFS-разделы на запись, но с некоторыми ограничениями.

Существует также ещё один способ монтирования 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, и, способов их решения, — будем дописывать в этой же статье.

Рекомендуемый контент

А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net

Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).

Источник

Ошибка ввода вывода hdd

Доброго времени суток! Есть жесткий диск на 3тб, который стоял в каком-то NAS от D-Link. Диск работал, потом попробовали воткнуть в Synology, который при попытке форматнуть диск выдал ошибку. Теперь диск форматнуть не получается. Gparted не видит таблицу разделов. При попытке определить диск выдает:

Ошибка синхронизации или закрытия файлов /dev/sdb: Ошибка ввода/вывода

При попытке выполнить

Есть какие-нибудь идеи или это труп? Диск относительно свежий, год ему. Данные мне не нужны, а вот диск — напротив.

Найди в 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

Прошу прощения, спойлер почему-то не работает. Вот вывод sudo hdparm -I /dev/sdb:

Security:
Master password revision code = 65534
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level high

Меня смущают эти строки. Может пасс стоит на нем?

Доброго времени суток! Упал с 3-го этажа, теперь идёт кровь из ног, торчат какие-то белые штуки, при попытке встать теряю сознание. Дополз до 3-го этажа и упал заново — не помогает. Дополз до другого здания и ещё раз упал с 3-го этажа — симптомы те же.

P.S. man dmesg и man smartctl

Очень забавно, однако диска не было у меня до сегодняшнего дня. И все манипуляции с насами не Я выполнял.

P.S. Я неправильно вывод dmesg посмотрел?

Правильно. Но в NAS’ах тоже можно посмотреть SMART, если что. Если диску «почти год» — самое время прямо сейчас бежать в магазин и менять его по гарантии.

У меня нет на руках этих насов. В smartctl тоже ошибки, тесты не выполняет. В общем труп, судя по всему. Спасибо всем, за уделенное время.

Не надо тесты выполнять (и так понятно, что они не пройдут), надо попробовать посмотреть smartctl -A /dev/sdX

Источник