Gentoo Archives: gentoo-user

From: Mick <michaelkintzios@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] USB crucial file recovery
Date: Tue, 30 Aug 2016 05:47:13
Message-Id: 1521951.1Rv3lY7YKZ@dell_xps
In Reply to: Re: [gentoo-user] USB crucial file recovery by Grant
1 On Monday 29 Aug 2016 17:51:19 Grant wrote:
2 > >>>>> I have a USB stick with a crucial file on it (and only an old backup
3 > >>>>> elsewhere). It's formatted NTFS because I wanted to be able to open
4 > >>>>> the file on various Gentoo systems and my research indicated that
5 > >>>
6 > >>>NTFS
7 > >>>
8 > >>>>> was the best solution.
9 > >>>>>
10 > >>>>> I decided to copy a 10GB file from a USB hard disk directly to the
11 > >>>
12 > >>>USB
13 > >>>
14 > >>>>> stick this morning and I ran into errors so I canceled the operation
15 > >>>>> and now the file manager (thunar) has been stuck for well over an
16 > >>>
17 > >>>hour
18 > >>>
19 > >>>>> and I'm getting errors like these over and over:
20 > >>>>>
21 > >>>>> [ 2794.535814] Buffer I/O error on dev sdc1, logical block 2134893,
22 > >>>>> lost async page write
23 > >>>>> [ 2794.535819] Buffer I/O error on dev sdc1, logical block 2134894,
24 > >>>>> lost async page write
25 > >>>>> [ 2794.535822] Buffer I/O error on dev sdc1, logical block 2134895,
26 > >>>>> lost async page write
27 > >>>>> [ 2794.535824] Buffer I/O error on dev sdc1, logical block 2134896,
28 > >>>>> lost async page write
29 > >>>>> [ 2794.535826] Buffer I/O error on dev sdc1, logical block 2134897,
30 > >>>>> lost async page write
31 > >>>>> [ 2794.535828] Buffer I/O error on dev sdc1, logical block 2134898,
32 > >>>>> lost async page write
33 > >>>>> [ 2794.535830] Buffer I/O error on dev sdc1, logical block 2134899,
34 > >>>>> lost async page write
35 > >>>>> [ 2794.535832] Buffer I/O error on dev sdc1, logical block 2134900,
36 > >>>>> lost async page write
37 > >>>>> [ 2794.535835] Buffer I/O error on dev sdc1, logical block 2134901,
38 > >>>>> lost async page write
39 > >>>>> [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902,
40 > >>>>> lost async page write
41 > >>>>> [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result:
42 > >>>>> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
43 > >>>>> [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error
44 > >>>
45 > >>>[current]
46 > >>>
47 > >>>>> [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No additional
48 > >>>
49 > >>>sense
50 > >>>
51 > >>>>> information
52 > >>>>> [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4
53 > >>>>> 58 00 00 f0 00
54 > >>>>> [ 2842.568859] blk_update_request: I/O error, dev sdc, sector
55 > >>>
56 > >>>17081432
57 > >>>
58 > >>>>> [ 2842.568862] buffer_io_error: 20 callbacks suppressed
59 > >>>>>
60 > >>>>> nmon says sdc is 100% busy but doesn't show any reading or writing.
61 > >>>
62 > >>>I
63 > >>>
64 > >>>>> once pulled the USB stick in a situation like this and I ended up
65 > >>>>> having to reformat it which I need to avoid this time since the file
66 > >>>>> is crucial. What should I do?
67 > >>>>>
68 > >>>>> - Grant
69 > >>>>
70 > >>>> Whatever you do, do NOT try to unplug the USB you were writing to
71 > >>>
72 > >>>unless you
73 > >>>
74 > >>>> first manage to successfully unmount it. If you do pull the USB
75 > >>>
76 > >>>stick
77 > >>>
78 > >>>> regardless of its current I/O state you will likely corrupt whatever
79 > >>>
80 > >>>file you
81 > >>>
82 > >>>> were writing onto, or potentially more.
83 > >>>>
84 > >>>> You could well have a hardware failure here, which manifested itself
85 > >>>
86 > >>>during
87 > >>>
88 > >>>> your copying operation. Things you could try:
89 > >>>>
90 > >>>> Run lsof to find out which process is trying to access the USB fs and
91 > >>>
92 > >>>kill it.
93 > >>>
94 > >>>> Then see if you can remount it read-only.
95 > >>>>
96 > >>>> Run dd, dcfldd, ddrescue to make an image of the complete USB stick
97 > >>>
98 > >>>on your
99 > >>>
100 > >>>> hard drive and then try to recover any lost files with testdisk.
101 > >>>>
102 > >>>> Use any low level recovery tools the manufacturer may offer - they
103 > >>>
104 > >>>will likely
105 > >>>
106 > >>>> require MSWindows.
107 > >>>>
108 > >>>> Shut down your OS and disconnect the USB stick, then reboot and try
109 > >>>
110 > >>>again to
111 > >>>
112 > >>>> access it, although I would first create an image of the device using
113 > >>>
114 > >>>any of
115 > >>>
116 > >>>> the above tools.
117 > >>>
118 > >>>dd errored and lsof returned no output at all so I tried to reboot but
119 > >>>even that hung after the first 2 lines of output so I did a hard reset
120 > >>>after waiting an hour or so. Once it came back up I tried to do 'dd
121 > >>>if=/dev/sdb1 of=usbstick' but I got this after awhile:
122 > >>>
123 > >>>dd: error reading ‘/dev/sdb1’: Input/output error
124 > >>>16937216+0 records in
125 > >>>16937216+0 records out
126 > >>>8671854592 bytes (8.7 GB) copied, 230.107 s, 37.7 MB/s
127 > >>>
128 > >>>It's a 64GB USB stick. dmesg says:
129 > >>>
130 > >>>[ 744.729873] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK
131 > >>>driverbyte=DRIVER_SENSE
132 > >>>[ 744.729879] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error
133 > >>>[current]
134 > >>>[ 744.729883] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read
135 > >>>error
136 > >>>[ 744.729886] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 78 e0
137 > >>>00 00 f0 00
138 > >>>[ 744.729889] blk_update_request: critical medium error, dev sdb,
139 > >>>sector 16939232
140 > >>>[ 744.763468] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK
141 > >>>driverbyte=DRIVER_SENSE
142 > >>>[ 744.763472] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error
143 > >>>[current]
144 > >>>[ 744.763474] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read
145 > >>>error
146 > >>>[ 744.763478] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 00
147 > >>>00 00 04 00
148 > >>>[ 744.763480] blk_update_request: critical medium error, dev sdb,
149 > >>>sector 16939264
150 > >>>[ 744.763482] Buffer I/O error on dev sdb1, logical block 4234304,
151 > >>>async page read
152 > >>>[ 744.786743] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK
153 > >>>driverbyte=DRIVER_SENSE
154 > >>>[ 744.786747] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error
155 > >>>[current]
156 > >>>[ 744.786750] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read
157 > >>>error
158 > >>>[ 744.786753] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 04
159 > >>>00 00 04 00
160 > >>>[ 744.786755] blk_update_request: critical medium error, dev sdb,
161 > >>>sector 16939268
162 > >>>[ 744.786758] Buffer I/O error on dev sdb1, logical block 4234305,
163 > >>>async page read
164 > >>>
165 > >>>I haven't tried to mount it yet. Any suggestions?
166 > >>>
167 > >>>- Grant
168 > >>>
169 > >> Try ddrescue.
170 > >> It tries to skip the really bad parts.
171 > >>
172 > >> Then try data recovery on copies of the resulting image file.
173 > >
174 > > I did:
175 > >
176 > > # ddrescue -d -r3 /dev/sdb usb.img usb.log
177 > > GNU ddrescue 1.20
178 > > Press Ctrl-C to interrupt
179 > > rescued: 62742 MB, errsize: 32768 B, current rate: 0 B/s
180 > >
181 > > ipos: 8672 MB, errors: 1, average rate: 14878 kB/s
182 > > opos: 8672 MB, run time: 1h 10m 17s, remaining time: n/a
183 > >
184 > > time since last successful read: 5s
185 > >
186 > > # mount -o loop,ro usb.img /mnt/usbstick
187 > > mount: wrong fs type, bad option, bad superblock on /dev/loop0,
188 > >
189 > > missing codepage or helper program, or other error
190 > >
191 > > In some cases useful info is found in syslog - try
192 > > dmesg | tail or so.
193 > >
194 > > # mount -o loop,ro -t ntfs usb.img /mnt/usbstick
195 > > NTFS signature is missing.
196 > > Failed to mount '/dev/loop0': Invalid argument
197 > > The device '/dev/loop0' doesn't seem to have a valid NTFS.
198 > > Maybe the wrong device is used? Or the whole disk instead of a
199 > > partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
200 > >
201 > > How else can I get my file from the ddrescue image of the USB stick?
202 > >
203 > > - Grant
204 >
205 > Ah, I got it, I just needed to specify the offset when mounting.
206 > Thank you so much everyone. Many hours of work went into the file I
207 > just recovered.
208 >
209 > So I'm done with NTFS forever. Will ext2 somehow allow me to use the
210 > USB stick across Gentoo systems without permission/ownership problems?
211 >
212 > - Grant
213
214 ext2 will work, but you'll have to mount it or chmod -R 0777, or only root
215 will be able to access it. There are also vfat and exfat fs, the latter can
216 be accessed with sys-fs/fuse-exfat on Linux. I think if you're only storing
217 files less than 4GB you better stay with vfat, which has a more space efficient
218 12KB cluster size.
219 --
220 Regards,
221 Mick

Replies

Subject Author
Re: [gentoo-user] USB crucial file recovery Neil Bothwick <neil@××××××××××.uk>