Partition corrupted

[orionis]

hello everyone

I have a big problem

since 3 year i have a ceph cluster for my data.

for this i have a pool of 9TO and i created a vm disk of 8.5TO.

few day i have one OSD full. i do a little procedure. Out osd for write on vm disk. clean lot of unused file on my vm disk for liberate space.

and clean the out osd before put in.



normally all work fine. but this time no.



When i reboot the VM with the VM disk the partiton on vm disk can't be mounted.

I thinks it was the rebalance/recovery was not completed but today is finish; but nothing

when i try recover partion i have this:

Code: Select all

 Bad magic number in super-block

fsck.ext4: Superblock invalid, trying backup blocks...

fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb



The superblock could not be read or does not describe a valid ext2/ext3/ext4

filesystem.  If the device is valid and it really contains an ext2/ext3/ext4

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>

 or

    e2fsck -b 32768 <device>



Found a gpt partition table in /dev/sdb

i try e2fsck -b 8193 /dev/sdb but work nothing . it start and it seem like freeze.



please how i can fix it. i have lot of data what i d'ont care but there are (photo and document i can't replace)





Thanks

[lindi]

Not sure if this helps but "/dev/sdb" is not a partition, it is the whole disk?

[orionis]

sorry /dev/sdb1.

[pbear]

I've yet to see a case where the superblock error could be fixed.* If you don't have backups, take a look at TestDisk for data recovery.

* Don't have a big history on this forum, but all Linux forums combined is something like 10,000 posts. I've seen the superblock issue several dozen times.

[CwF]

I've yet to see a case where the superblock error could be fixed.

It happens...

Code: Select all

# fsck -b 32768 /dev/sda
fsck from util-linux 2.29
e2fsck 1.43.3 (04-Sep-2016)
/dev/sda was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda: 11/7331840 files (0.0% non-contiguous), 475411/29305206 blocks

Still in use...

[pbear]

It happens...

At the risk of sounding dense, where does that output indicate superblock repair? FWIW, it's the form of command I've recommended many times (though never had need myself).

Edit: Just noticed something. Every source I've seen says to run the command against the partition, yet I notice yours specifies the device. Is that where I've been going sideways all this time?

[CwF]

where does that output indicate superblock repair?

I assume this part

/dev/sda: ***** FILE SYSTEM WAS MODIFIED *****

Didn't mount before, did after. Has happened a few times.
gparted's 'check' also works.

[orionis]

the output repair do nothing it freeze.
same i try testdisk i can list lly files but when i try to copy . some file can be copied but some other freeze the system.

i stand on night dont progress it freeze or turn in loop

[CwF]

Every source I've seen says to run the command against the partition, yet I notice yours specifies the device.

Good question. I can't say for sure. This is from my notes from a few years ago, that's what it is. In my standard way there are only partitions on an lvm OS, I never partition otherwise so I'm sure that here there is only one partition.

@orionis My example is also from a vm with the whole disk passed raw to the vm. The notes I pull this from also state I used fsck only that once, and used gparted within the VM to do the check 3 times after that. All due to power outages over a 3 year span. All hard drives, ssd's present in the system did not scramble during these outages. Since then I am more likely not to pass a raw spinning disk.

[pbear]

the output repair do nothing it freeze.

You have tried both ways, right? Meaning, you identified a backup superblock and ran fsck -b against both the device and the partition. If that didn't work, there isn't any other solution (of which I'm aware).
If TestDisk doesn't work either, you could try professional data recovery, but expensive and no guaranty. Frankly, this scenario is a good example of why we do backups.