My ext4 backup (rotating) disk has died. I get this error It can't rewrite block 16777216 anyhow, and the next errors will be for groups 1,2,3, … -->∞.

I was guessing something filesystem pivotal was stored on block 16777216,which accounts for the massive error count. But likewise, block 16777216 must have a massive number of read/writes.

I don't need the data, as I have 90% of the backup backed up on an offline disk. What I do know is that surgery is required and I need the best filesystem tools to see if the disk is worth saving. Probably not.

Is there a way to prevent to repeat occurrence? Likewise, what format offers good repair tools?

Probably it's the superblock. There are copies of it scattered through the filesystem and they're supposed to be identical.

Don't know what the 'best' repair tool is but I'd check into fsck as it seems to be popular. I've personally not had to 'fix' a drive. The few times I've had 'bad' drives they were 'clicking and making funny noises' ... I just replaced. The disk format I always use is ext4 for all my systems (and backup internal and external drives). No LVM either. Just ext4. Always have had good luck with it.

first of all I would try smartctl. And replace disk.

It's a backup disk primarily, but it's been online 100% of the time lately. Nothing gets used except at backups and two directories. So to my mind, it's died young. I'm buying one but as an ex-maintenance guy, I'm interested.

Smartctl report attached. Looks cooked to me, certainly as a backup disk. fsck is just calls a format-specific tool, and I worry about the lack of maturity. e2fsck has been there from the year dot.

I'll clear off and buy myself a disk.

Attached Files

esmartctl.txt (6.5 KB, 18 views)

As Hazel points out, it could be a bad superblock - be worth trying with a different one before consigning it to the bin.

It hasn't gone in the bin.

I've ordered a 1TB to replace it, and left it aside. I did say it was probably filesystem pivotal, so I'm pretty sure it's a superblock. But I don't want it as a backup disk any more. I'll have a go at reshaping it, do the smartctl long test and use it as a media disk, maybe.

On the other filesystems, I took a look at the tools, and reiserfs or xfs look reasonably detailed fsck tools, to judge by the man pages.

Good plan -- replacing the drive. They are cheap and save a lot of wondering and worry. Any more, there isn't really a good reason to play around with a bad/going bad disk drive ... unless you really really really have something important you need to get off of it of course.

I also always have one replacement drive in my storage cabinet, in case my server internal backup drive goes bad. My server data drives are all SSDs. I've also added 'external' bays to my server - one 3.5 bay (hold 1 full size hdd) and one 2.5 bay (holds 6 SATA SSDs), so I don't have to open the box. Just shutdown, pull tray out and replace drive and restart.

The days were where a drive gradually went bad, and you could often back up mission critical stuff on the same drive, and expect to have it. Now imho, the 'going' stage has vanished out of disks. It's good, or it's gone. It's young, and nothing happened to make me say "I deserved this," so I'm a bit put out. Nevertheless, when a 600G drive starts identifying as a 1TB drive, the writing is on the wall. There's that sector, too and how many more?

I'll operate at my leisure, and expect it not to survive the operation. For instance, while the disk was good, I listed it's partuuid in /etc/fstab as "5f216f6c-01". Parted 'recovered' that partition, with partuuid "1858e3fb-01". All files are gone. Need I add more?

Update:

My new disk purchase arrived today. Meanwhile, the old one seems to be degraded to curiosity status.

I mentioned it was oversizing itself, a 593/600G disk now identifying as 931.5/1000G. I remade the partition. Badblocks had recorded no errors. I made a single 600G partition, and copied on about 600G of data. But the disk was by now identifying the partition as 931.5G. Once you make a filesystem, the available size shrinks anyhow. But this thing thought it had hundreds of Gigs free. So I set rsync duplicating a directory of 275G, to see was it real.

For a while it was copying away fine. We went up to 682/600G + filesystem overhead, and then my rsync sat down with error 30 (broken pipe) and the disk electronically vanished. Powering the disk down, unmounting & killing all process with open files on it was next. Then it behaved itself. I can play the last but one video it copied over. It crashed on episode 12, I can play episode 10, in excess of 675/600G And it still thinks it has 189G free

But would I trust anything that goes out to lunch electronically? No way. That lasts while it lasts, and no longer. It's a curious way for a disk to go, certainly. I tried to find an error for block 16777216 with smartctl & badblocks, but no dice. And no dice with e2fsck once I remade the partition.