„Błąd wejścia / wyjścia” podczas uzyskiwania dostępu do katalogu

Chcę wyświetlić i usunąć zawartość katalogu na wymiennym dysku twardym. Ale wystąpił „Błąd wejścia / wyjścia”:

$ rm  pic -R
rm: cannot remove `pic/60.jpg': Input/output error
rm: cannot remove `pic/006.jpg': Input/output error
rm: cannot remove `pic/008.jpg': Input/output error
rm: cannot remove `pic/011.jpg': Input/output error

$ ls -la pic
ls: cannot access pic/60.jpg: Input/output error
-????????? ? ?    ?         ?            ? 006.jpg
-????????? ? ?    ?         ?            ? 006.jpg
-????????? ? ?    ?         ?            ? 011.jpg

Zastanawiałem się, na czym polega problem?

Jak mogę odzyskać lub usunąć katalog pici całą jego zawartość?

Mój system operacyjny to Ubuntu 12.04, a wymienny dysk twardy ma system plików NTFS. Inne katalogi nie zawierające picwymiennego dysku twardego lub znajdujące się w nim działają poprawnie.

Dodany:

Ostatnia część wyniku dmesgpo próbie wyświetlenia zawartości katalogu:

[19000.712070] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[19000.853167] usb-storage 1-1:1.0: Quirks match for vid 05e3 pid 0702: 520
[19000.853195] scsi5 : usb-storage 1-1:1.0
[19001.856687] scsi 5:0:0:0: Direct-Access     ST316002 1A               0811 PQ: 0 ANSI: 0
[19001.858821] sd 5:0:0:0: Attached scsi generic sg2 type 0
[19001.861733] sd 5:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[19001.862969] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.865223] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.865232] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.867597] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.869214] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.869218] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.891946]  sdb: sdb1
[19001.894713] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.895950] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.895953] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.895958] sd 5:0:0:0: [sdb] Attached SCSI disk
[19113.024123] usb 2-1: new high-speed USB device number 3 using ehci_hcd
[19113.218157] scsi6 : usb-storage 2-1:1.0
[19114.232249] scsi 6:0:0:0: Direct-Access     USB 2.0  Storage Device   0100 PQ: 0 ANSI: 0 CCS
[19114.233992] sd 6:0:0:0: Attached scsi generic sg3 type 0
[19114.242547] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[19114.243144] sd 6:0:0:0: [sdc] Write Protect is off
[19114.243154] sd 6:0:0:0: [sdc] Mode Sense: 08 00 00 00
[19114.243770] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.243778] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.252797] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.252807] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.280407]  sdc: sdc1 < sdc5 >
[19114.289774] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.289779] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.289783] sd 6:0:0:0: [sdc] Attached SCSI disk

Błędy wejścia / wyjścia podczas prób dostępu do systemu plików zazwyczaj oznaczają problemy ze sprzętem.

Wpisz dmesgi sprawdź ostatnie kilka wierszy wyniku. Jeśli dysk lub połączenie z nim nie powiedzie się, zostanie to odnotowane.

EDYCJA Czy montujesz go za pomocą ntfslub ntfs-3g? Jak pamiętam, starszy ntfssterownik nie miał stabilnej obsługi zapisu i został w dużej mierze porzucony, gdy okazało się, że ntfs-3gjest znacznie bardziej stabilny i bezpieczny.

Jak twierdzi Sadhur, jest to prawdopodobnie spowodowane problemami ze sprzętem dysku, a dane dmesgwyjściowe są właściwym miejscem do sprawdzenia tego.

Możesz wykonać skanowanie powierzchni dysku z Linuksa /sbin/badblocks /dev/sda.

Sprawdź stronę podręcznika, aby uzyskać dokładniejsze testy podstawowych poprawek (relokacja bloków). Wszystko zależy od systemu plików, więc jest bezpieczne nawet w systemie plików NTFS, ponieważ działa na poziomie „powierzchni dysku”.

Zrobiłem to osobiście, aby uruchamiało się co miesiąc z crona. Oczywiście musisz sprawdzić, czy otrzymujesz wiadomości Cron ze swojej skrzynki pocztowej (co często nie jest prawdą). Te wiadomości kończą się w /var/mail/$USERpodobny sposób.

Stworzyłem /etc/cron.d/badblocks:

30 4 * * 3 root [ -x /sbin/badblocks ] && [ $(date +\%d) -le 7 ] && /sbin/badblocks /dev/sda

Twój system plików jest uszkodzony, w przypadku woluminów NTFS powinieneś uruchomić chkdsksystem Windows, ale odzyskanie go jest prawie niemożliwe. Czasami może być konieczne sformatowanie dysku.

Rozwiązaniem, które działa dla mnie, jest obniżenie ntfs-3gwersji z wersji 2014 na wersję 2012. To powinno rozwiązać problem z dostępem do partycji NTFS. Na dłuższą metę nie jest to rozwiązanie, ponieważ w końcu będziesz musiał uruchomić najnowszą wersję.

Więcej informacji tutaj

Chciałem po prostu dodać moje rozwiązanie do tego wątku z korzyścią dla innych - pracowałem nad systemem, gdy mój zasilacz się zepsuł - musiałem ponownie podłączyć kable SATA w niewłaściwej kolejności, ponieważ kiedy je przełączyłem, wszystko działało ponownie - nie mam pojęcia, dlaczego dysk rozruchowy musiał znajdować się na określonym porcie SATA, i tak może być odpowiedzią dla kogoś innego.

Nikt nie wspominał, co zrobić, jeśli narzędzia Linux nie działają i dostępny jest tylko Mac, ale nie Windows.

Może być naprawiony w systemie OS X z Paragon NTFS

W moim przypadku gpartedpowiedziałem, aby znaleźć komputer z systemem Windows, którego nigdzie nie można było znaleźć. Ale był już Mac, dla którego dostępne jest to wspaniałe oprogramowanie. Zainstalowałem wersję próbną, wykonałem weryfikację , a następnie naprawę - i voilà!

Chciałem tylko podzielić się swoim doświadczeniem: na FreeBSD 10.3 zamontowałem zewnętrzny dysk twardy

$ sudo ntfs-3g /dev/da0s1 /media

Na dysku twardym zrobiłem a, mkdiraby utworzyć katalog, a następnie przeniosłem do niego niektóre pliki, oczywiście za pomocą mvpolecenia. W końcu wykonałem następujące polecenie:

$ sudo sync

Następnie zamontowałem dysk twardy na komputerze z systemem Linux z jądrem 4.4.0-78-generic. Teraz, gdy wymienię zawartość dysku twardego, katalog utworzony we FreeBSD o nazwie Jeffjest pokazany jak poniżej:

$ ls -lhrtci
ls: cannot access 'Jeff': Input/output error
total 20K
  ? d????????? ? ?    ?       ?            ? Jeff

Ponadto podczas próby usunięcia Jeffkatalogu pojawia się następujący komunikat o błędzie:

$ sudo rm -f -R Jeff
rm: cannot remove 'Jeff': Input/output error

Nie mogłem pozbyć się Jeffkatalogu na maszynie z Linuksem, dlatego użyłem maszyny FreeBSD i ponownie zamontowałem dysk twardy na FreeBSD. Ale ls, cdi rmpolecenia na FreeBSD generować takie same Input/output error. Wygląda na to, że wystąpił błąd w ntfs-3gpakiecie FreeBSD .

AKTUALIZACJA

Przeniosłem wszystkie moje dane z zewnętrznego dysku twardego na maszynę z systemem Linux, oczywiście Jeffnie można przenieść uszkodzonego pliku z powodu błędu we / wy. Następnie sformatowałem zewnętrzny dysk twardy z zerowaniem woluminu i sprawdzaniem uszkodzonego sektora w następujący sposób:

$ sudo mkfs.ntfs /dev/sdb1

A następnie przenieśli wszystkie dane z powrotem na wolumin zewnętrzny. W ten sposób straciłem uszkodzony plik o nazwie Jeff, jednak mój zewnętrzny dysk twardy jest czysty od wszelkich błędów we / wy.

Zwolniłem, że kiedy próbuję uzyskać dostęp do dysku, na którym występuje ten błąd, próbowałem zapisać ostatnie skopiowane pliki zostały nadpisane do ostatniego pliku, a następnie próba dostępu kończy się niepowodzeniem, ponieważ zapisany już rekord nie pasuje do ostatnio skopiowanych elementów, więc nie udaje się. Najzdrowszym sposobem na uratowanie dysku jest usunięcie ostatniego elementu lub elementów skopiowanych do systemu Windows.