Re: [gentoo-user] USB crucial file recovery
> On 31 Aug 2016, at 16:25, Grant wrote: > >> Yes, FAT. It works and works well. >> Or exFAT which is Microsoft's solution to the problem of very large >> files on FAT. > > FAT32 won't work for me since I need to use files larger than 4GB. I > know it's beta software but should exfat be more reliable than rtfs? There's always `split`. Very easy to use, just a little inconvenient to have to invoke it every time you copy a file to USB. Stroller.
Re: [gentoo-user] USB crucial file recovery
On Tue, 30 Aug 2016 13:32:19 -0700, Grant wrote: > If I use ext2 on the USB stick, can I mount and use it as any user on > any Gentoo system from within a file manager like thunar? No, because ext2 uses proper Linux file permissions. > Should I consider ext3/4 with journaling disabled? That's basically ext2, unless you want some of the more advanced options of ext4. -- Neil Bothwick I've got a Mickey Mouse PC with a Goofy operating system. pgpIoJvpANJ1G.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
On Tue, 30 Aug 2016 20:12:12 +0200, Alan McKinnon wrote: > >> OP is looking for an fs to put on a memory stick that will work > >> everywhere: > >> > >> - vfat > >> - exfat > > > > He asked for something that would work "across Gentoo systems". > > > > > > How does exfat not fulfil that? It does fulfil it, but so does ext2, which you were ruling out by saying it had to work everywhere. My main issue with exfat is its lack of maturity. I use it for video files but I'm not sure I'd trust something critical to it. There again, I'd rather not trust anything critical to a USB stick regardless of filesystem. -- Neil Bothwick A real programmer never documents his code. It was hard to make, it should be hard to read pgpnwlAQ5cF5f.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
Am 30.08.2016 um 22:32 schrieb Grant: ext2 doesn't have a journal, that's why I suggested it in the first > place. My point was against all the journalised filesystems (that includes NTFS), not against your advice ;) >>> OP is looking for an fs to put on a memory stick that will work >>> everywhere: >>> >>> - vfat >>> - exfat >> He asked for something that would work "across Gentoo systems". >> >> > How does exfat not fulfil that? > > because exfat does not work across gentoo systems. ext2 does. >>> Exfat works when the drivers are installed. >>> Same goes for ext2. >>> >>> It is possible to not have support for ext2/3 or 4 and still have a fully >>> functional system. (Btrfs or zfs for the full system for instance) >>> >>> When using UEFI boot, a vfat partition with support is required. >>> >>> -- >>> Joost >> ext2 is on every system, exfat not. ext2 is very stable, tested and well >> aged. exfat is some fuse something crap. New, hardly tested and unstable >> as it gets. >> >> And why use exfat if you use linux? It is just not needed at all. > > If I use ext2 on the USB stick, can I mount and use it as any user on > any Gentoo system from within a file manager like thunar? > > Should I consider ext3/4 with journaling disabled? > > - Grant > > kde and lxde never had any problems on my systems.
Re: [gentoo-user] USB crucial file recovery
On Tue, Aug 30, 2016 at 4:32 PM, Grant wrote: >> >> ext2 is on every system, exfat not. ext2 is very stable, tested and well >> aged. exfat is some fuse something crap. New, hardly tested and unstable >> as it gets. >> > > If I use ext2 on the USB stick, can I mount and use it as any user on > any Gentoo system from within a file manager like thunar? > Ext2 will work on any Gentoo system that has it enabled in the kernel, the same as just about any filesystem that has been created. Ext2 support is fairly likely to be enabled due to its ubiquity, but you can certainly run a linux kernel without it, as has already been pointed out. If you stick your USB drive in an Android phone, for example, you might just find that it lacks support for the filesystem (no doubt many/most Android systems using it for the OS, but since it is a closed ecosystem with 100% flash they might also use f2fs, yaffs, or even btrfs (which can be quite stable if you carefully control how it is used, especially on read-only filesystems)). -- Rich
Re: [gentoo-user] USB crucial file recovery
>>> ext2 doesn't have a journal, that's why I suggested it in the >>> first place. >>> My point was against all the journalised filesystems (that >>> includes >>> NTFS), not against your advice ;) >>> >> >> OP is looking for an fs to put on a memory stick that will work >> everywhere: >> >> - vfat >> - exfat > He asked for something that would work "across Gentoo systems". > > How does exfat not fulfil that? >>> because exfat does not work across gentoo systems. ext2 does. >> Exfat works when the drivers are installed. >> Same goes for ext2. >> >> It is possible to not have support for ext2/3 or 4 and still have a fully >> functional system. (Btrfs or zfs for the full system for instance) >> >> When using UEFI boot, a vfat partition with support is required. >> >> -- >> Joost > > ext2 is on every system, exfat not. ext2 is very stable, tested and well > aged. exfat is some fuse something crap. New, hardly tested and unstable > as it gets. > > And why use exfat if you use linux? It is just not needed at all. If I use ext2 on the USB stick, can I mount and use it as any user on any Gentoo system from within a file manager like thunar? Should I consider ext3/4 with journaling disabled? - Grant
Re: [gentoo-user] USB crucial file recovery
Am 30.08.2016 um 21:14 schrieb J. Roeleveld: > On August 30, 2016 8:58:17 PM GMT+02:00, Volker Armin Hemmann > wrote: >> Am 30.08.2016 um 20:12 schrieb Alan McKinnon: >>> On 30/08/2016 14:04, Neil Bothwick wrote: On Tue, 30 Aug 2016 12:08:13 +0200, Alan McKinnon wrote: >>> ext2 doesn't have a journal, that's why I suggested it in the >> first >>> place. >> My point was against all the journalised filesystems (that >> includes >> NTFS), not against your advice ;) >> > > OP is looking for an fs to put on a memory stick that will work > everywhere: > > - vfat > - exfat He asked for something that would work "across Gentoo systems". >>> How does exfat not fulfil that? >>> >>> >> because exfat does not work across gentoo systems. ext2 does. > Exfat works when the drivers are installed. > Same goes for ext2. > > It is possible to not have support for ext2/3 or 4 and still have a fully > functional system. (Btrfs or zfs for the full system for instance) > > When using UEFI boot, a vfat partition with support is required. > > -- > Joost ext2 is on every system, exfat not. ext2 is very stable, tested and well aged. exfat is some fuse something crap. New, hardly tested and unstable as it gets. And why use exfat if you use linux? It is just not needed at all.
Re: [gentoo-user] USB crucial file recovery
On Sun, Aug 28, 2016 at 1:49 PM, Grant wrote: > 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: As mentioned try ddrescue and then recovery software on the resulting images. As a last option it is possible to desolder the flash and access it directly. Good information to lead with is how much the file cost to produce.
Re: [gentoo-user] USB crucial file recovery
On August 30, 2016 8:58:17 PM GMT+02:00, Volker Armin Hemmann wrote: >Am 30.08.2016 um 20:12 schrieb Alan McKinnon: >> On 30/08/2016 14:04, Neil Bothwick wrote: >>> On Tue, 30 Aug 2016 12:08:13 +0200, Alan McKinnon wrote: >>> >> ext2 doesn't have a journal, that's why I suggested it in the >first >> place. > > My point was against all the journalised filesystems (that >includes > NTFS), not against your advice ;) > OP is looking for an fs to put on a memory stick that will work everywhere: - vfat - exfat >>> >>> He asked for something that would work "across Gentoo systems". >>> >>> >> >> How does exfat not fulfil that? >> >> > >because exfat does not work across gentoo systems. ext2 does. Exfat works when the drivers are installed. Same goes for ext2. It is possible to not have support for ext2/3 or 4 and still have a fully functional system. (Btrfs or zfs for the full system for instance) When using UEFI boot, a vfat partition with support is required. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] USB crucial file recovery
Am 30.08.2016 um 20:12 schrieb Alan McKinnon: > On 30/08/2016 14:04, Neil Bothwick wrote: >> On Tue, 30 Aug 2016 12:08:13 +0200, Alan McKinnon wrote: >> > ext2 doesn't have a journal, that's why I suggested it in the first > place. My point was against all the journalised filesystems (that includes NTFS), not against your advice ;) >>> >>> >>> OP is looking for an fs to put on a memory stick that will work >>> everywhere: >>> >>> - vfat >>> - exfat >> >> He asked for something that would work "across Gentoo systems". >> >> > > How does exfat not fulfil that? > > because exfat does not work across gentoo systems. ext2 does.
Re: [gentoo-user] USB crucial file recovery
On 30/08/2016 14:04, Neil Bothwick wrote: On Tue, 30 Aug 2016 12:08:13 +0200, Alan McKinnon wrote: ext2 doesn't have a journal, that's why I suggested it in the first place. My point was against all the journalised filesystems (that includes NTFS), not against your advice ;) OP is looking for an fs to put on a memory stick that will work everywhere: - vfat - exfat He asked for something that would work "across Gentoo systems". How does exfat not fulfil that?
Re: [gentoo-user] USB crucial file recovery
On Tue, Aug 30, 2016 at 1:35 AM, Azamat Hackimov wrote: > > I would recommend to use F2FS filesystem, since you have only Linux systems. > As a user of immature filesystems, I would not recommend F2FS unless you want to be a user of immature filesystems. Remember how he got into this situation in the first place... But, sure, F2FS is fairly ideally-suited to a USB drive in theory, assuming the drive doesn't try to be overly clever with how it maps all the writes. -- Rich
Re: [gentoo-user] USB crucial file recovery
On Tue, 30 Aug 2016 12:08:13 +0200, Alan McKinnon wrote: > >> ext2 doesn't have a journal, that's why I suggested it in the first > >> place. > > > > My point was against all the journalised filesystems (that includes > > NTFS), not against your advice ;) > > > > > OP is looking for an fs to put on a memory stick that will work > everywhere: > > - vfat > - exfat He asked for something that would work "across Gentoo systems". -- Neil Bothwick I don't suffer from insanity. I enjoy every minute of it. pgpA_foIY7y2S.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
On Tue, 30 Aug 2016 11:43:13 +0200, Alarig Le Lay wrote: > On Tue Aug 30 10:40:01 2016, Neil Bothwick wrote: > > ext2 doesn't have a journal, that's why I suggested it in the first > > place. > > My point was against all the journalised filesystems (that includes > NTFS), not against your advice ;) That's a good point. For compatibility, exFAT seems a good choice, although I'm not sure how mature/stable it is on Linux. I've used it a little with no issues. -- Neil Bothwick In plumbing, a straight flush is better than a full house. pgpGSZdpMKoR3.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
On 30/08/2016 11:43, Alarig Le Lay wrote: > On Tue Aug 30 10:40:01 2016, Neil Bothwick wrote: >> ext2 doesn't have a journal, that's why I suggested it in the first place. > > My point was against all the journalised filesystems (that includes > NTFS), not against your advice ;) > OP is looking for an fs to put on a memory stick that will work everywhere: - vfat - exfat -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] USB crucial file recovery
On Tue Aug 30 10:40:01 2016, Neil Bothwick wrote: > ext2 doesn't have a journal, that's why I suggested it in the first place. My point was against all the journalised filesystems (that includes NTFS), not against your advice ;) -- alarig signature.asc Description: Digital signature
Re: [gentoo-user] USB crucial file recovery
On Tue, 30 Aug 2016 10:29:00 +0200, Alarig Le Lay wrote: > > So I'm done with NTFS forever. Will ext2 somehow allow me to use the > > USB stick across Gentoo systems without permission/ownership > > problems? > > I always use pmount for USB and other flash devices to have it > mounted with my user permissions at all times. > Anyway, I don’t recommend you to use a journalised filesystem on a USB > stick, as it liable to write wearing. You will deteriorate it > prematurely. ext2 doesn't have a journal, that's why I suggested it in the first place. -- Neil Bothwick What Aussies lack in Humour they make up for in Beer! pgpHGacqSL_vY.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
On Mon Aug 29 17:51:19 2016, Grant wrote: > So I'm done with NTFS forever. Will ext2 somehow allow me to use the > USB stick across Gentoo systems without permission/ownership problems? I always use pmount for USB and other flash devices to have it mounted with my user permissions at all times. Anyway, I don’t recommend you to use a journalised filesystem on a USB stick, as it liable to write wearing. You will deteriorate it prematurely. -- alarig
Re: [gentoo-user] USB crucial file recovery
On Mon, 29 Aug 2016 17:51:19 -0700, Grant wrote: > # ddrescue -d -r3 /dev/sdb usb.img usb.log > [...] > Ah, I got it, I just needed to specify the offset when mounting. Tht's because you ran ddrescue on the whole stick and not the partition containing the filesystem. > Thank you so much everyone. Many hours of work went into the file I > just recovered. > > So I'm done with NTFS forever. Will ext2 somehow allow me to use the > USB stick across Gentoo systems without permission/ownership problems? That depends on whether you use the same UID on each system. If not, mounting with umask=0 will make everything world writeable. -- Neil Bothwick Windows95: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. pgpJctnR_vxgi.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
On Tue, 30 Aug 2016 06:46:54 +0100, Mick wrote: > > So I'm done with NTFS forever. Will ext2 somehow allow me to use the > > USB stick across Gentoo systems without permission/ownership problems? > > > > - Grant > > ext2 will work, but you'll have to mount it or chmod -R 0777, or only > root will be able to access it. That's not true. Whoever owns the files and directories will be able to access then, even if root mounted the stick, just like a hard drive. If you have the same UID on all your systems, chown -R youruser: /mount/point will make everything available on all systems. -- Neil Bothwick As long as you do not move you can still choose any direction. pgpRFWM3mW6pg.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB crucial file recovery
On Monday 29 Aug 2016 17:51:19 Grant 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 Ke
Re: [gentoo-user] USB crucial file recovery
2016-08-30 5:51 GMT+05:00 Grant : > Ah, I got it, I just needed to specify the offset when mounting. > Thank you so much everyone. Many hours of work went into the file I > just recovered. > > So I'm done with NTFS forever. Will ext2 somehow allow me to use the > USB stick across Gentoo systems without permission/ownership problems? > > - Grant > > I would recommend to use F2FS filesystem, since you have only Linux systems. -- >From Siberia with Love!
Re: [gentoo-user] USB crucial file recovery
> 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 >>>driver
Re: [gentoo-user] USB crucial file recovery
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
Re: [gentoo-user] USB crucial file recovery
On August 29, 2016 3:24:18 AM GMT+02:00, Grant 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]
Re: [gentoo-user] USB crucial file recovery
>> 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 erro
Re: [gentoo-user] USB crucial file recovery
On Sunday 28 Aug 2016 11:49:44 Grant 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. Good luck. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] USB crucial file recovery
On Sun, 28 Aug 2016 11:49:44 -0700, Grant 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. If it's only to be used on Gentoo (or Linux) systems, why not ext2? > [ 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? That looks horribly like a hardware failure. The first step should be to see if you can dd the stick to an image file (without mounting it). Then you can work on the image file, or a copy of it, and try things like testdisk. If dd also gives hardware errors, ddrecsue may be able to recover some of it, hopefully including the important bits, but I'm not holding my breath for you :( -- Neil Bothwick When there's a will, I want to be in it. pgpKI2tw10OQb.pgp Description: OpenPGP digital signature
[gentoo-user] USB crucial file recovery
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
