[gentoo-user] e2fsck -a /dev/sdb1

[the...@sys-concept.com]

I'm trying to repair USB disk (64GB) originally formatted with ext4

I read the USB stick on Windows via some kind of windows ext4 driver now I can not open it on Linux box.

e2fsck -a /dev/sdb1
64gb: recovering journal

(just stays there and does nothing).
when I unplug it I get:

e2fsck: No such file or directory while trying to re-open 64gb

64gb: ********** WARNING: Filesystem still has errors **********

(dmesg):
usb-storage 8-1:1.0: USB Mass Storage device detected
[1175553.773966] scsi host8: usb-storage 8-1:1.0
[1175554.790598] scsi 8:0:0:0: Direct-Access Verbatim STORE N GO 5.00 PQ: 0 ANSI: 6
[1175554.791142] sd 8:0:0:0: Attached scsi generic sg2 type 0
[1175558.511554] sd 8:0:0:0: [sdb] 120933888 512-byte logical blocks: (61.9 GB/57.7 GiB)
[1175558.511720] sd 8:0:0:0: [sdb] Write Protect is off
[1175558.511722] sd 8:0:0:0: [sdb] Mode Sense: 23 00 00 00
[1175558.511890] sd 8:0:0:0: [sdb] No Caching mode page found
[1175558.511891] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[1175558.514906] sdb: sdb1
[1175558.515986] sd 8:0:0:0: [sdb] Attached SCSI removable disk
[1176008.633223] usb 8-1: USB disconnect, device number 46
[1176008.641063] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[1176008.641069] sd 8:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 01 38 08 00 00 00 08 00
[1176008.641073] blk_update_request: I/O error, dev sdb, sector 20449280
[1176008.641076] Buffer I/O error on dev sdb1, logical block 2555904, lost async page write
[1176008.641113] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[1176008.641116] sd 8:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 01 3c 08 00 00 00 08 00
[1176008.641118] blk_update_request: I/O error, dev sdb, sector 20711424
[1176008.641120] Buffer I/O error on dev sdb1, logical block 2588672, lost async page write
[1176008.651400] VFS: Dirty inode writeback failed for block device sdb1 (err=-5).

--
Thelma

[J. Roeleveld]

Try increasing verbosity of the e2fsck....

And why would you trust some random ms windows ext4 driver in RW mode?

--
Joost
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[the...@sys-concept.com]

Increasing verbosity doesn't help much :-/
e2fsck -v /dev/sdb1
e2fsck 1.43.3 (04-Sep-2016)
64gb: recovering journal

e2fsck: No such device or address while trying to re-open 64gb

64gb: ********** WARNING: Filesystem still has errors **********

I had copied bunch of picture from my box into largest USB disk I could
find on my desk, little I realized that that disk had been format to ext4.
When I went to presented it (I had only Windows box available) and had
to use some kind of "ext" driver from http://www.ext2fsd.com/ to read
the disk on Windows.

--
Thelma

[Helmut Jarausch]

On 06/15/2017 06:21:44 PM, the...@sys-concept.com wrote:

> > Try increasing verbosity of the e2fsck....

> >\u200b

> > And why would you trust some random ms windows ext4 driver in RW
> mode?

> >\u200b

> > --
> > Joost
>
> Increasing verbosity doesn't help much :-/
> e2fsck -v /dev/sdb1
> e2fsck 1.43.3 (04-Sep-2016)
> 64gb: recovering journal
>
> e2fsck: No such device or address while trying to re-open 64gb
>
> 64gb: ********** WARNING: Filesystem still has errors **********
>
> I had copied bunch of picture from my box into largest USB disk I
> could
> find on my desk, little I realized that that disk had been format to
> ext4.
> When I went to presented it (I had only Windows box available) and had
> to use some kind of "ext" driver from http://www.ext2fsd.com/ to read
> the disk on Windows.
>
> --
> Thelma
>

This looks like a hardware failure. You could try to use
sys-fs/ddrescue
to recover all / most files.
If this doesn't work as expected, you can try to use app-admin/testdisk.

Then you can format the drive and copy the files back.

P.S. Have you used the "save eject feature" of Windows before
disconnection the drive from your PC?

(Cheap) USB sticks are by no means a safe data storage.

If you don't change any data while the drive is attached to Windows try
using a stick with a write protection toggle.
If you have to write to the drive from Windows it would be better to
format it as NTFS which can be read/written on Linux.

Helmut

[the...@sys-concept.com]

On 06/15/2017 10:48 AM, Helmut Jarausch wrote:
> On 06/15/2017 06:21:44 PM, the...@sys-concept.com wrote:
>

[snip]

>>
>
> This looks like a hardware failure. You could try to use sys-fs/ddrescue
> to recover all / most files.
> If this doesn't work as expected, you can try to use app-admin/testdisk.
>
> Then you can format the drive and copy the files back.
>
> P.S. Have you used the "save eject feature" of Windows before
> disconnection the drive from your PC?
>
> (Cheap) USB sticks are by no means a safe data storage.
>
> If you don't change any data while the drive is attached to Windows try
> using a stick with a write protection toggle.
> If you have to write to the drive from Windows it would be better to
> format it as NTFS which can be read/written on Linux.
>
> Helmut

I don't really need any of the files that were on this USB stick.
I was trying to recover the ext4 file system on this USB but it didn't work.

I was under impression that ext4 file system was much better (not prone
to these kind of damages) but I was wrong.

--
Thelma

[Mick]

On Thursday 15 Jun 2017 11:24:09 the...@sys-concept.com wrote:

> I was under impression that ext4 file system was much better (not prone
> to these kind of damages) but I was wrong.
>
> --
> Thelma

If you remove the USB disk while the PC is accessing it, the electrical
discharge across the physical contacts of the USB connector can cause terminal
damage to the onboard chipset controller.

If you're lucky only partial corruption of the filesystem occurs and the USB
disk can be used again. If you are very lucky and no I/O operations were
being performed at the time the USB will suffer no damage. I try to remember
to unmount the USB before I remove it, but I had to learn this the hard way.
--
Regards,
Mick

[J. Roeleveld]

Ext4, and any other filesystem, is only as reliable as the implementation.

Using a random, rarely tested, implementation is often a bad idea.

Simply unplugging a USB drive can easily kill the entire filesystem. If I see a person simply pulling it out without ejecting first will never get one of mine...

[Nikos Chantziaras]

On 15/06/2017 06:26 μμ, the...@sys-concept.com wrote:
> I'm trying to repair USB disk (64GB) originally formatted with ext4
>
> I read the USB stick on Windows via some kind of windows ext4 driver now I can not open it on Linux box.
>
> e2fsck -a /dev/sdb1
> 64gb: recovering journal
>
> (just stays there and does nothing).
> when I unplug it I get:
>
> e2fsck: No such file or directory while trying to re-open 64gb

If you don't need the files on the stick (as you mentioned on another
post), then I'd recommend formatting it using exfat. Works on both Linux
and Windows. Emerge sys-fs/fuse-exfat and mounting exfat sticks will
happen automatically, just like as if it was ext4.

To format the stick you can use sys-fs/exfat-utils (it installs
mkfs.exfat.) Or format it under Windows. You probably should erase the
partition first under Linux though so that Windows sees all space as
unclaimed. Just remember to select exfat instead of fat32 when you
format it.

[Mick]

On Thursday 15 Jun 2017 21:40:30 dan...@sonck.nl wrote:
> On Jun 15, 2017 9:28 PM, Mick <michael...@gmail.com> wrote:

> This is the first time I heard about discharge damage while unplugging. I
> highly doubt that but for curiosity sake I like some document
> proving/explaining this.

I'd like one too, but until one appears have a look at what's happening in
this video around 0:46min.

https://www.youtube.com/watch?v=PdiJWQmSi0k

The principle is similar. There is current flow and unplugging the conductors
apart causes an arc. Of course the voltages involved are much smaller and so
is the damage.


> What I think is more likely is, flash memory needs special consideration
> when writing to. If the driver inside the USB flash drive did not have
> enough time to write out all it's accounting data on where to write stuff
> and it's cycles, the flash will be damaged.

Not really. What you describe should only damage the filesystem not the chip
controller, or the semiconductor material. I've experienced hardware failure
on USB drives which were removed during a writing cycle.


> At least I assume this holds
> for flash as it does for SSD. Both are limited in write cycles, and I'd
> assume both use a similar technique, though I have no proof to back this
> up.
>
> Greetings,
>
> Daniel

I've read that industrial NAND flash devices (Single Layer Cell construction)
are less prone to fs damage because they include capacitors to flush any
controller buffers not yet written to the device when the forced disconnection
occurs. Allegedly they also have better electro-static-discharge protection.
Consumer grade devices are less graceful in the event of a disconnection.


PS. Can you please refrain from posting HTML messages to this mailing list.
Many old-timers lurking around here are still using text only (teletype)
terminals. :p

--
Regards,
Mick

[Rich Freeman]

On Thu, Jun 15, 2017 at 3:37 PM, Mick <michael...@gmail.com> wrote:
> On Thursday 15 Jun 2017 21:40:30 dan...@sonck.nl wrote:
>> On Jun 15, 2017 9:28 PM, Mick <michael...@gmail.com> wrote:
>
>> This is the first time I heard about discharge damage while unplugging. I
>> highly doubt that but for curiosity sake I like some document
>> proving/explaining this.
>
> I'd like one too, but until one appears have a look at what's happening in
> this video around 0:46min.
>
> https://www.youtube.com/watch?v=PdiJWQmSi0k
>
> The principle is similar. There is current flow and unplugging the conductors
> apart causes an arc. Of course the voltages involved are much smaller and so
> is the damage.
>

You're comparing a 500kV breaker at a substation to a USB device?

I'm very skeptical of the claim that any electrical effects associated
with unplugging a device is going to cause issues with any USB device.
They're basically designed to be hot swapped.

Now, the filesystem is an entirely different matter - disconnecting a
mounted filesystem can cause all kinds of issues. I think this is the
most likely issue people are going to run into, and of course you
should not have a mounted filesystem when removing a device. Some
filesystems are more resilient to this sort of thing than others.

I would think that something like a log-based filesystem like f2fs
would be pretty impervious to loss of anything but uncommitted data.
COW filesystems should also be pretty resilient. Filesystems set to
journal data should be fine, but ones that overwrite data in-place
might be left in a somewhat inconsistent state. I suspect this
applies even when using ordered data mode on something like ext4 (your
metadata is going to be fine, but if you were overwriting 15 blocks
in-place I'd think that you could end up in a situation where half are
updated and half are not). I'd be interested in somebody who knows
better on this last point. Ideally you want the failure mode to be
that the state of of the disk corresponds to what you would expect at
the conclusion of a write system call (maybe not all the calls in the
cache, but it should end on a boundary).

I'd also buy the argument that some poorly designed USB drives could
end up with data loss to something other than the block being
immediately written, but honestly I'm skeptical that this is a
widespread problem.

--
Rich

[Daniel Frey]

On 06/15/2017 12:28 PM, Mick wrote:
> If you remove the USB disk while the PC is accessing it, the electrical
> discharge across the physical contacts of the USB connector can cause terminal
> damage to the onboard chipset controller.
>
> If you're lucky only partial corruption of the filesystem occurs and the USB
> disk can be used again. If you are very lucky and no I/O operations were
> being performed at the time the USB will suffer no damage. I try to remember
> to unmount the USB before I remove it, but I had to learn this the hard way.
>

This is the first I've heard of this. I have witnessed our staff at
working plugging something in and having static discharge fry a USB
stick, but I've never seen that happen while unplugging.

I tell staff to touch the computer case before plugging it in first.
When a user fries one I asked if they touched the case first and the
answer is always "no".

Dan

[Peter Humphrey]

On Thursday 15 Jun 2017 23:37:22 Mick wrote:

> Many old-timers lurking around here are still using text only
> (teletype) terminals. :p

ASR-33, KSR-35. Takes me back, does that, to a two-day course on their
maintenance. 1974.

--
Regards
Peter

[Mick]

On Thursday 15 Jun 2017 15:47:03 Rich Freeman wrote:

> You're comparing a 500kV breaker at a substation to a USB device?
>
> I'm very skeptical of the claim that any electrical effects associated
> with unplugging a device is going to cause issues with any USB device.
> They're basically designed to be hot swapped.

The comparison was made tongue-in-cheek to illustrate the point. I don't know
what the probabilities are but on at least two occasions I ended up with a USB
stick which had a large number of bad blocks and partially destroyed files.
This was a relatively young, but cheap USB stick. The I/O errors were quite
high and over-writing the blocks with zeros did not fix the problem. I've
come across this problem on two different USB sticks, probably because I was
the go to guy for recovering data in an office full of MSWindows PCs.

> I'd also buy the argument that some poorly designed USB drives could
> end up with data loss to something other than the block being
> immediately written, but honestly I'm skeptical that this is a
> widespread problem.

Losing the odd files because of unplugging a USB stick during a write
operation is a regular occurrence. Ending up with large numbers of bad blocks
is a rare phenomenon in my experience. I blamed the problem on cheap USB
sticks not being able to cope with the enthusiastic unplugging they were
submitted to, which caused semiconductor breakdown or damage to the USB
controller chip. At the time I thought the wear levelling chip went sideways
and was no longer able to re-allocate sectors. Attempts to fix the bad blocks
were unreliable and after some time using smartctl and dd to zero badblocks I
gave up.
--
Regards,
Mick

[Mick]

Yes, ESD can fry anything up, including you MoBo. I've damaged a CPU once
because I was working on a nylon carpet without wearing a ESD wrist band. I
thought I had earthed on the chassis at the time, but it seems I moved enough
on the carpet to cause an ESD. :-(

--
Regards,
Mick

[Helmut Jarausch]

I've read that one should use SDFormatter version 4 (on Windows)

Helmut

[Nikos Chantziaras]

Never heard of it. Sounds like it's for SD cards, not USB sticks?