[SOLVED] Read only disk

business_kid · 01-26-2024, 01:24 PM

I've a backup partition on which I ran 'e2fsck -fvy' It was modifed.
It threw a write 'Input/output error' on logging the fault. It's in a usb caddy.

It reads fine. I conclude e2fsck has decided it's smarter than me, which is probably true. So it has locked out the disk. But I can't back much stuff up like this.

There's no cron job waiting, but how do I untie that knot?

pan64 · 01-27-2024, 06:41 AM

depends on the disk, probably I would run a disk check (see smartctl). Also check logs, probably there is a related message somewhere. Check the error code (exit code) of fsck (see man page about it).

business_kid · 01-27-2024, 02:30 PM

Well, it's amazing what a night's rest does. It mounts & reads fine, and loss will be small if I have to toss it. But it's now a different story.

Code:

root@Ebony:~# e2fsck -C 0 -Dfv /dev/sdc3
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdc3: recovering journal
e2fsck: unable to set superblock flags on /dev/sdc3


/dev/sdc3: ********** WARNING: Filesystem still has errors **********

No trouble with the journal was reported yesterday. So I tried a few times. It couldn't fix the superblock, so I went in with

Code:

root@Ebony:~# e2fsck -b 98304  -C 0 -fv /dev/sdc3 
e2fsck 1.46.5 (30-Dec-2021)
e2fsck: No such file or directory while trying to open /dev/sdc3
Possibly non-existent device?
root@Ebony:~# e2fsck -b 98304  -C 0 -fv /dev/sdc3 
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Error reading block 8913624 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913625 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913626 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913627 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913628 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite ('a' enables 'yes' to all) <y>? yes
Error reading block 8913629 (Input/output error) while getting next inode from scan.  Ignore error ('a' enables 'yes' to all) <y>? yes
Force rewrite ('a' enables 'yes' to all) <y>? yes
Error reading block 8913630 (Input/output error) while getting next inode from scan.  Ignore error ('a' enables 'yes' to all) <y>? yes
Force rewrite<y>? yes
Error reading block 8913631 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913632 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913633 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 8913634 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes # and miles more of it

The 'non-existent device' error was because I had hit Ctrl_C in e2fsck. Strange.

Once I'm seeing these Input/Output errors, I'm thinking surface errors, and that the device is past it's "Use by' date. It's dated 2020-12-28. I don't actually need much, or even any data from it, as it's storage is duplicated. So I can toss it if required. I'll probably set badblocks on it tomorrow. Does anyone see a route to recovery for it? It's spinning rust in a usb caddy, Western Digital, Model 10SPXZ-11Z10T0

business_kid · 01-28-2024, 07:16 AM

Well, I can proclaim a result. The disk is gone. Here's today's dialog

Code:

root@Ebony:~#badblocks -e 15 -s -o sdc3test.log /dev/sdc3
Checking for bad blocks (read-only test): Too many bad blocks, aborting test0/0 errors))rs)
done
root@Ebony:~#

# So I tried the error log

root@Ebony:~# cat sdc3test.log
412342272
412342273
412342274
412342275
412342276
412342277
412342278
412342279
412342280
412342281
412342282
412342283
412342284
412342285
412342286
root@Ebony:~#

The '-e 15' on sdc3 stopped badblocks if it found 15 bad blocks. There's only 14 blocks in the log, but I presume I presume block 412342287 was bad, and it exited without logging it. In e2fsck, I had got impressive numbers of Input/Output errors, and said "yes to all" and watched them roll off the screen. If I'd been prepared to wait the 4¾ hours, I would have got the (impressive) total count. But imho, the last thing you want is an iffy backup disk.

I know from previous tests there's more than one bad patch appeared on it. Not a great lifespan from it, to be sure. I confess to not treating it particularly kindly, and it was in circuit when that power supply blew and took out the motherboard. Maybe that was the issue all along.

One thing I'm taking away from e2fsck's behaviour is this:

Code:

Error reading block 8913624 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes

If I don't press 'y', e2fsck quit. Likewise with the 'force rewrite'. That's a very M$-like choice for e2fsck to give. I'm not interested in marking them bad, as many more are probably ready to follow them.

jefro · 01-28-2024, 11:09 AM

Part of the issue may be that drive controller firmware/hardware/software might work with MS. In my experience it doesn't mean Linux will work as expected on usb drives. From power to cable to timing issues can all wreck havoc.

business_kid · 01-28-2024, 11:20 AM

Quote:

Originally Posted by jefro

Part of the issue may be that drive controller firmware/hardware/software might work with MS...

I/O errors? Bad Blocks? Really? They are surface errors. I have a few usb drives and this is the first trouble from any of them. Personally, I prefer the blown Power supply theory as you've plenty of lively ans spikey inductors there

business_kid · 01-31-2024, 10:30 AM

Postscript:

Having binned the offending drive, I found that Debian's install had wiped my other most-up-to-date backup during installation. Maybe I told it to. The partition involved was mounted as /home on Debian. So I extracted my read-only disk from the (fortunately unemptied) bin, put it in a usb caddy and read it one last time.

It read perfectly. But

It randomly shut the power off twice during the 2 hours I was using it.
If I powered up while it was in a usb socket, the boot order changed. Instead of the default Slackware boot, it threw me up a page saying there was a problem with my (M$) Windows boot setup and please (do something silly).

The boot thing could be explained only if the BIOS ignored the pre-set boot order and gave priority to the usb drive, which also has a boot partition.

Try as I might, I can't think of a rational or logical explanation for those issues. It does seem to point to electronics issues as the fault condition. With the levels of integration we have today, semiconductor design permutations are nearly infinite. So in a repair scenario, you're allowed to believe in ghosts or gremlins if you want; because those approaches make as much sense as logic.