On August 29, 2016 3:24:18 AM GMT+02:00, Grant <emailgr...@gmail.com> wrote: >>> I have a USB stick with a crucial file on it (and only an old backup >>> elsewhere). It's formatted NTFS because I wanted to be able to open >>> the file on various Gentoo systems and my research indicated that >NTFS >>> was the best solution. >>> >>> I decided to copy a 10GB file from a USB hard disk directly to the >USB >>> stick this morning and I ran into errors so I canceled the operation >>> and now the file manager (thunar) has been stuck for well over an >hour >>> and I'm getting errors like these over and over: >>> >>> [ 2794.535814] Buffer I/O error on dev sdc1, logical block 2134893, >>> lost async page write >>> [ 2794.535819] Buffer I/O error on dev sdc1, logical block 2134894, >>> lost async page write >>> [ 2794.535822] Buffer I/O error on dev sdc1, logical block 2134895, >>> lost async page write >>> [ 2794.535824] Buffer I/O error on dev sdc1, logical block 2134896, >>> lost async page write >>> [ 2794.535826] Buffer I/O error on dev sdc1, logical block 2134897, >>> lost async page write >>> [ 2794.535828] Buffer I/O error on dev sdc1, logical block 2134898, >>> lost async page write >>> [ 2794.535830] Buffer I/O error on dev sdc1, logical block 2134899, >>> lost async page write >>> [ 2794.535832] Buffer I/O error on dev sdc1, logical block 2134900, >>> lost async page write >>> [ 2794.535835] Buffer I/O error on dev sdc1, logical block 2134901, >>> lost async page write >>> [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902, >>> lost async page write >>> [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result: >>> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE >>> [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error >[current] >>> [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No additional >sense >>> information >>> [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4 >>> 58 00 00 f0 00 >>> [ 2842.568859] blk_update_request: I/O error, dev sdc, sector >17081432 >>> [ 2842.568862] buffer_io_error: 20 callbacks suppressed >>> >>> nmon says sdc is 100% busy but doesn't show any reading or writing. >I >>> once pulled the USB stick in a situation like this and I ended up >>> having to reformat it which I need to avoid this time since the file >>> is crucial. What should I do? >>> >>> - Grant >> >> Whatever you do, do NOT try to unplug the USB you were writing to >unless you >> first manage to successfully unmount it. If you do pull the USB >stick >> regardless of its current I/O state you will likely corrupt whatever >file you >> were writing onto, or potentially more. >> >> You could well have a hardware failure here, which manifested itself >during >> your copying operation. Things you could try: >> >> Run lsof to find out which process is trying to access the USB fs and >kill it. >> Then see if you can remount it read-only. >> >> Run dd, dcfldd, ddrescue to make an image of the complete USB stick >on your >> hard drive and then try to recover any lost files with testdisk. >> >> Use any low level recovery tools the manufacturer may offer - they >will likely >> require MSWindows. >> >> Shut down your OS and disconnect the USB stick, then reboot and try >again to >> access it, although I would first create an image of the device using >any of >> the above tools. > > >dd errored and lsof returned no output at all so I tried to reboot but >even that hung after the first 2 lines of output so I did a hard reset >after waiting an hour or so. Once it came back up I tried to do 'dd >if=/dev/sdb1 of=usbstick' but I got this after awhile: > >dd: error reading ‘/dev/sdb1’: Input/output error >16937216+0 records in >16937216+0 records out >8671854592 bytes (8.7 GB) copied, 230.107 s, 37.7 MB/s > >It's a 64GB USB stick. dmesg says: > >[ 744.729873] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK >driverbyte=DRIVER_SENSE >[ 744.729879] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error >[current] >[ 744.729883] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read >error >[ 744.729886] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 78 e0 >00 00 f0 00 >[ 744.729889] blk_update_request: critical medium error, dev sdb, >sector 16939232 >[ 744.763468] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK >driverbyte=DRIVER_SENSE >[ 744.763472] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error >[current] >[ 744.763474] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read >error >[ 744.763478] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 00 >00 00 04 00 >[ 744.763480] blk_update_request: critical medium error, dev sdb, >sector 16939264 >[ 744.763482] Buffer I/O error on dev sdb1, logical block 4234304, >async page read >[ 744.786743] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK >driverbyte=DRIVER_SENSE >[ 744.786747] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error >[current] >[ 744.786750] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read >error >[ 744.786753] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 04 >00 00 04 00 >[ 744.786755] blk_update_request: critical medium error, dev sdb, >sector 16939268 >[ 744.786758] Buffer I/O error on dev sdb1, logical block 4234305, >async page read > >I haven't tried to mount it yet. Any suggestions? > >- Grant
Try ddrescue. It tries to skip the really bad parts. Then try data recovery on copies of the resulting image file. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
