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 pic
i 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 pic
wymiennego dysku twardego lub znajdujące się w nim działają poprawnie.
Dodany:
Ostatnia część wyniku dmesg
po 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
Odpowiedzi:
Błędy wejścia / wyjścia podczas prób dostępu do systemu plików zazwyczaj oznaczają problemy ze sprzętem.
Wpisz
dmesg
i 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ą
ntfs
lubntfs-3g
? Jak pamiętam, starszyntfs
sterownik nie miał stabilnej obsługi zapisu i został w dużej mierze porzucony, gdy okazało się, żentfs-3g
jest znacznie bardziej stabilny i bezpieczny.źródło
ntfs-3g
?mount
polecenie i patrząc na wynik.dmesg
po próbie wyświetlenia zawartości katalogu. Nie wiem jak to pomaga. (2) Nie widzę, czy jest montowany przez nfts-3g czy ntfs, patrząc na wynikimount
:/dev/sdb1 on /media/removable_drive type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
fuseblk
oznacza, że używa metodyfuser
system plików w przestrzeni użytkownika, z którejntfs-3g
korzysta. Więc jesteś dobry pod tym względem.Jak twierdzi Sadhur, jest to prawdopodobnie spowodowane problemami ze sprzętem dysku, a dane
dmesg
wyjś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/$USER
podobny sposób.Stworzyłem
/etc/cron.d/badblocks
:źródło
/sbin/badblocks /media/removable_drive
w moim przypadku należy wykonać polecenie, które zasugerowałeś ?/sbin/badblocks /dev/sdb
lub sdc. Naprawdę nie mogę zrozumieć, co się stało / zrobiłeś zdmesg
/dev/sd{x}
dysk za pomocąfdisk -l
poleceniaTwój system plików jest uszkodzony, w przypadku woluminów NTFS powinieneś uruchomić
chkdsk
system Windows, ale odzyskanie go jest prawie niemożliwe. Czasami może być konieczne sformatowanie dysku.źródło
badblocks
komendę w systemie Linux.Rozwiązaniem, które działa dla mnie, jest obniżenie
ntfs-3g
wersji 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
źródło
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.
źródło
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
gparted
powiedział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à!źródło
Chciałem tylko podzielić się swoim doświadczeniem: na FreeBSD 10.3 zamontowałem zewnętrzny dysk twardy
Na dysku twardym zrobiłem a,
mkdir
aby utworzyć katalog, a następnie przeniosłem do niego niektóre pliki, oczywiście za pomocąmv
polecenia. W końcu wykonałem następujące polecenie: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
Jeff
jest pokazany jak poniżej:Ponadto podczas próby usunięcia
Jeff
katalogu pojawia się następujący komunikat o błędzie:Nie mogłem pozbyć się
Jeff
katalogu na maszynie z Linuksem, dlatego użyłem maszyny FreeBSD i ponownie zamontowałem dysk twardy na FreeBSD. Alels
,cd
irm
polecenia na FreeBSD generować takie sameInput/output error
. Wygląda na to, że wystąpił błąd wntfs-3g
pakiecie FreeBSD .AKTUALIZACJA
Przeniosłem wszystkie moje dane z zewnętrznego dysku twardego na maszynę z systemem Linux, oczywiście
Jeff
nie 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: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.źródło
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.
źródło