ext4 - data loss after power failure, and unable to recover

Obviously one should expect data loss after a power failure, that's why we run fsck on boot.

However being unable to subsequently recover your filesystem is unfortunate: the "unable to set superblock flags" error is interesting. Ted, any ideas?

Don't know if this is related but i'm trying to figure out why karmic is unable to create ext4 on several older drives (6.4 to 10 GB)

On the other hand, Jaunty installs just fine on those drives but when i boot up from a karmic live CD, then the karmic live CD is not able to read ext3 partition, it detects sda but not the actual partitions sda1 and the sda5 swap.

And another thing: when i want mount a drive that i tried to partition with the karmic installer (i386 desktop, alternat and server all the same) then those drives appear to have a bad superblock and are not accessible from ANY system (Ubuntu 8.04 to 9.10, windows xp, and even with tools like on the ultimate boot cd i'm not able to fix the bad superblock)

But for some magical reason that i don't understand, i can use a jaunty live CD and install ubuntu (while loosing all the data) and the bad superblock appears to be fixed.

And another thing... I also lost a partition on a external harddrive (also bad superblock..) ext3 partition that got lost while working with a ubuntu karmic install. I'm becoming a bit paranoia of these issues, and i hope it is just coincidence, but something tells me there is more to it and maybe i better go back to jaunty untill i see this fixed.

A personal note: i think it was a bad choice to choose for ext4 beta and grub2 beta together on this release. It works, but i doubt it's stability. And i'm missing an EASY way to CHOOSE during the install to use ext3 and grub0.95 INSTEAD of ext4 and grub2. Infact i would have preferred ext3 and grub0.95 still as default until ext4 and grub2 are out of beta and STABLE.
(a bit more like Debian)

Is this post enough to get this looked at or should i post a new bug report?

Uaname, I'd suggest opening another bug report since the problem with not being able to see partitions with the karmic sounds like it may be a much more fundamental problem --- I suspect some kind of kernel issue where the Karmic kernel isn't compatible with your "older drives". You should specify in that new bug report what kind of drives they are --- SATA? IDE? (I suspect IDE) and what controller they are using. An output of the dmesg on boot of the Karmic kernel and the Jaunty kernel would also be useful. I'm guessing that your older drives are using IDE, and there is some kind of problem with the IDE driver that simply wasn't caught during testing, since it's been a number of years since computers have been sold with IDE, and so it's less likely that Ubuntu testers would have caught that problem.

As far as ext4 is concerned, it's out of beta as far as I'm concerned, and for desktop use it should be quite stable. There are some specific ext4 features which are in beta, but they aren't enabled by default. (More on one of them in a bit.) The "failed to set superblock flags" is an error that is normally caused by a corrupted journal file. My apologies for not looking at this sooner but the original bug report got lost in my inbox. If you still have the corrupted disk, I can probably help you recover it, but I'm guessing you've since reformatted the disk. If it's any comfort (and I doubt it will be), the exact same thing could have just as easily happened with ext3. The journal checksum feature is still in beta (and so it's not enabled by default), and that might have been able to detect the corrupted journal transaction and skip it, minimizing the damage.

Best regards,

-- Ted

Hello,

I've had power loss on my linux router. After I booted i've received the following error message:

fsck.ext3: unable to set superblock flags on /dev/hda9

Here is what I have tried so far:

mke2fs -n /dev/hda9
fsck.ext3 -b <superblock> /dev/hda9 (i tried all superblocks from mke2fs output)

the error message always is the same:

Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
fsck.ext3: unable to set superblock flags on /dev/hda9

I got this error on 3 of my partitions hda6 7 and 9.

Data is intact on all of them. Just this error message I am unable to fix.

Please help to fix this.
Thanks in advance,
Julian

Had the same problem as imperia777 : data intact, error message and unable to fix it, (though no actual power failure).

Here's fsck output:

e2fsck 1.42.9 (4-Feb-2014)
myfsname: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway? yes

fsck.ext4: unable to set superblock flags on myfsname

Final verdict was: defective storage.
Data was transferred to a new storage medium with a new filesystem.
Problem solved.

As additional check, we made a copy from the defective medium to another and observed that fsck could run flawlessly on the sane medium.

Looks like fsck is extra cautious and checks if every operations indeed happened, which allowed it to spot the trouble.

Anyway, to say it again: "fsck.ext4: unable to set superblock flags on myfsname" meant (at least in my case): change your storage medium.
Thank you for your attention.