Bad superblock on dev как исправить

Different Fault Causes this Error:

In addition to trying to mount a disk instead of a partition (see accepted answer), there’s another problem which causes the same error to be puked:

Attempting to mount a partition without a filesystem.

In below example, please substitute the X in «/dev/sdX1″ with your own disk designation and the «1» with the partition number you want to format with the filesystem.

Error:

I was indeed mounting a partition and not an entire disk as was the case with the OP’s error when I executed:

mount -t vfat /dev/sdX1 /media/userName

but nonetheless received the same error:

«mount: /media/userName: wrong fs type, bad option, bad superblock on
/dev/sdX1, missing codepage or helper program, or other error«

Diagnostics:

I checked the filesystem type on the partition against the one I was specifying in the mount command:

df -Th /dev/sdX1

This returned devtmpfs; clearly this was not correct.

Solution:

Format the partition with a filesystem and remount:

sudo mkfs.vfat /dev/sdX1

sudo mount -t vfat /dev/sdX1 /media/userName

The mount now succeeds.

If you execute

df -Th /dev/sdX1

the FS Type now reports «vfat«

Conclusion:

I had a Homer Simpson moment. I had partitioned the disk but got called away before I laid down a filesystem on the new partition. Thus, of course the mount command failed.

D’Oh!

Why do I get «wrong fs type, bad option, bad superblock» error?

When mounting an NFS directory by doing:

I get the following error:

The kernel is up to date.

The question was already asked (for example here and here), but are either not answered or the answers are not helpful in my case.

6 Answers 6

The error message mentions:

(for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount. helper program)

This is relevant given that you are trying to mount NFS. The /sbin/mount.nfs helper program is provided by nfs-common . You can install it with:

On the other hand, if you are trying to mount CIFS, the helper program is provided by cifs-utils . You can install it with:

Make sure mount.cifs is listed into /sbin :

Check to see if package cifs-utils is installed:

If it isn’t, install the cifs libraries with

It appears that nfs-common package should be installed in order to be able to mount NFS directories.

When it’s not, the mounting of an NFS directory results in the error I’ve got.

I solved it by installing virtualbox. Do

It installs the mount.vboxsf

I was having this same problem in Ubuntu 14.04 LTS. I tried the nfs-common package install without any success.

I was able to resolve the same issue you had by:

1. Going to the Linux «disks» application.
2. Clicking the USB drive I was trying to mount in the devices section (window left).
3. Clicking more actions under the Volumes filesystem partition section (two little gears right of the minus/plus signs).
4. Clicking edit mount options (top of the mount options window).
5. Clicking to TURN ON Automatic Mount Options.
6. Then clicking the mount button (+ sign under volumes) — this should change to a square.

This mounted my USB drive and resolved the issue.

Источник

Не монтируется диск hdd

После переустановки системы, подключил к компу диск с данными /dev/sdb
Делаю mount -t ext4 /dev/sdb /usr/local
Выводит следующее:

В dmesg : EXT4-fs (sdb): VFS: Can’t find ext4 filesystem

Команда: fsck -fy /dev/sdb
Выводит:

Если сделать fsck -fy /dev/sdb1
То будет следующее сообщение, а далее тысячи исправлений:

Больше ничего не делал, боюсь потерять данные.
Как восстановить диск? точнее примонтировать и не потерять даные.

ФС ведь не была создана прямо на диске? Раз уж это жёсткий диск, наверное, там есть таблица разделов.

Поздно, потери уже в пути.

После переустановки системы, подключил к компу диск с данными /dev/sdb

Что именно произошло с диском между переустановкой и переподключением?

Перестало работать после того , как я через gparted изменил UUID

mount -t ext4 -o sb=32768 /dev/sdb1 /mnt тоже не сработает?

Если есть место, лучше считать весь sdb1 куда-нибудь и работать с его копиями.

Testdisk может прочитать список файлов на разделе?

К сожалению, нет возможности скопировать данные куданить
Testdisk выдаёт это

Народ. ну что? делать Write partition structure to disk ? ничего лишнего не затрёт?

Список файлов прочесть с помощью Testdisk можно!

Какие ошибки появляются в dmesg при попытке смонтировать sdb с -o sb=8193, -o sb=32768 и без -o?

Если ФС так и не смонтируется, можно попробовать считать самые важные файлы при помощи testdisk.

На все вырианты одно

sdb1 же — запарили уже тупить

[ 267.924107] EXT4-fs (sdb): VFS: Can’t find ext4 filesystem

featurelles , прошу прощения, моя опечатка. Естественно, в предыдущем сообщении имелся в виду sdb1.

Если через testdisk попробовать сделать востановление суперблока, выбором Write partition structure to disk это ведь на диске ничего не попортит?

Просто запускайте testdisk /dev/sdb1 и выбирайте Non partitioned media.

Я пробовал и sdb и sdb1 , везде одно и тоже.
Но эт уже не важно, сейчас копии файлов делаю. И далее через testdisk попробую восстановить хард.(раньше об этой проге и не слышал)
AITap — огромное спасибо за помощь!

Источник

Problem FAQ

Contents

General topics

How do I report bugs and issues?

Please report bugs on Bugzilla on kernel.org (requires registration) setting the component to Btrfs, and report bugs and issues to the mailing list (linux-btrfs@vger.kernel.org; you are not required to subscribe). For quick questions you may want to join the IRC #btrfs channel on libera.chat (and stay around for some time in case you do not get the answer right away).

Please use btrfs-progs somewhere in the bug subject if you’re reporting a bug for the userspace tools.

If you include kernel log backtraces in bug reports sent to the mailing list, please disable word wrapping in your mail user agent to keep the kernel log in a readable format.

Please attach files (like logs or dumps) directly to the bug and don’t use pastebin-like services.

Mount/unmount problems

I can’t mount my filesystem, and I get a kernel oops!

First, update your kernel to the latest one available and try mounting again. If you have your kernel on a btrfs filesystem, then you will probably have to find a recovery disk with a recent kernel on it.

Second, try mounting with options -o recovery or -o ro or -o recovery,ro (using the new kernel). One of these may work successfully.

Finally, if and only if the kernel oops in your logs has something like this in the middle of it,

then you should try using btrfs rescure zero-log (see Manpage/btrfs-rescue).

Filesystem can’t be mounted by label

See the next section.

Only one disk of a multi-volume filesystem will mount

If you have labelled your filesystem and put it in /etc/fstab, but you get:

or if one volume of a multi-volume filesystem fails when mounting, but the other succeeds:

Then you need to ensure that you run a btrfs device scan first:

This should be in many distributions’ startup scripts (and initrd images, if your root filesystem is btrfs), but you may have to add it yourself.

My filesystem won’t mount and none of the above helped. Is there any hope for my data?

Maybe. Any number of things might be wrong. The restore tool is a non-destructive way to dump data to a backup drive and may be able to recover some or all of your data, even if we can’t save the existing filesystem.

Unsorted/uncategorized

Defragmenting a directory doesn’t work

does not defragment the contents of the directory.

This is by design. btrfs fi defrag operates on the single filesystem object passed to it, e.g. a (regular) file. When ran on a directory, it defragments the metadata held by the subvolume containing the directory, and not the contents of the directory. If you want to defragment the contents of a directory, you have to use the recursive mode with the -r flag (see recursive defragmentation).

Compression doesn’t work / poor compression ratios

First of all make sure you have passed «compress» mount option in fstab or mount command. If yes, and ratios are unsatisfactory, then you might try «compress-force» option. This way you make the btrfs to compress everything. The reason why «compress» ratios are so low is because btrfs very easily backs out of compress decision. (Probably not to waste too much CPU time on bad compressing data).

Copy-on-write doesn’t work

You’ve just copied a large file, but still it consumed free space. Try:

I get the message «failed to open /dev/btrfs-control skipping device registration» from «btrfs dev scan»

You are missing the /dev/btrfs-control device node. This is usually set up by udev. However, if you are not using udev, you will need to create it yourself:

You might also want to report to your distribution that their configuration without udev is missing this device.

I get «No space left on device» errors, but df says I’ve got lots of space

First, check how much space has been allocated on your filesystem:

Note that in this case, all of the devices (the only device) in the filesystem are fully utilised. This is your first clue.

Next, check how much of your metadata allocation has been used up:

Note that the Metadata used value is fairly close (75% or more) to the Metadata total value, but there’s lots of Data space left. What has happened is that the filesystem has allocated all of the available space to either data or metadata, and then one of those has filled up (usually, it’s the metadata space that does this). For now, a workaround is to run a partial balance:

Note that there should be no space between the -d and the usage. This command will attempt to relocate data in empty or near-empty data chunks (at most 5% used, in this example), allowing the space to be reclaimed and reassigned to metadata.

If the balance command ends with «Done, had to relocate 0 out of XX chunks», then you need to increase the «dusage» percentage parameter till at least one chunk is relocated. More information is available elsewhere in this wiki, if you want to know what a balance does, or what options are available for the balance command.

I cannot delete an empty directory

First case, if you get:

• rmdir: failed to remove ‘emptydir’: Operation not permitted

then this is probably because «emptydir» is actually a subvolume.

You can check whether this is the case with:

To delete the subvolume you’ll have to run:

Second case, if you get:

• rmdir: failed to remove ‘emptydir’: Directory not empty

then you may have an empty directory with a non-zero i_size.

You can check whether this is the case with:

Running «btrfs check» on that (unmounted) filesystem will confirm the issue and list other problematic directories (if any).

You will get a similar output (excerpt):

Such errors should be fixable with «btrfs check —repair» provided you run a recent enough version of btrfs-progs.

Note that «btrfs check —repair» should not be used lightly as in some cases it can make a problem worse instead of fixing anything.

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

[SOLVED]mount: wrong fs type, bad option, bad superblock

[SOLVED]mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Sun Apr 27, 2014 4:48 pm

I’m trying to mount a vfat partition on my external hard drive. I know the drive works because it automatically mounts on my MacBook just fine.

The way it’s set up is as follows:

Re: mount: wrong fs type, bad option, bad superblock

Post by Mute Ant » Sun Apr 27, 2014 9:48 pm

I am only guessing here because I only have one drive that big, formatted with ext4. It is possible that the magic built into the ‘auto’ part is failing, so tell it exactly what you want and where just this once.

sudo mount -t vfat /dev/sdb2 /mnt

Who wired this up for you? You bought it in a shop? Oo what a terrible job.

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Sun Apr 27, 2014 10:56 pm

I did it myself because I want a backup drive for my MacBook and at the same time I’m not going to dedicate a whole 1TB for that. It’s an external drive.

I tried using vfat instead of auto like you said. Still no dice.

Re: mount: wrong fs type, bad option, bad superblock

Post by Spearmint2 » Mon Apr 28, 2014 12:31 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 1:11 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 2:59 pm

I forget what the limit is for a vfat partition, but I think 500GB is well in excess.

If you don’t have any data stored on it yet, format it ntfs if you need to share it with windows otherwise consider ext3/4.

Good luck

Re: mount: wrong fs type, bad option, bad superblock

Post by Spearmint2 » Mon Apr 28, 2014 3:29 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 3:58 pm

But will dosfstools or mount -t vfat be compatible

I once formated a a 32GIG flash with -F16 and had a similar problem when copying files to it. I then used -F32 and it was fine.

Re: mount: wrong fs type, bad option, bad superblock

Post by Spearmint2 » Mon Apr 28, 2014 4:36 pm

They should. Here’s my Linux box with FAT32 partitions larger than 32 GB on it.

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 5:19 pm

Well I guess I have to stand corrected then

Nothing was mentioned in the vfat kernel documentation about that, just the addition of long file names.

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 5:39 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 7:58 pm

Just out of curiosity did you try it on a windows system Did you try formatting it vfat on a windows system

I still suspect vfat at 500GB, but I’m often wrong

Re: mount: wrong fs type, bad option, bad superblock

Post by Mute Ant » Mon Apr 28, 2014 9:11 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 9:19 pm

It mounts on Windows as well. So that just leaves Mint.

Of course, the HFS partition doesn’t mount, and I don’t expect it to. I’m only talking about the VFAT. Windows doesn’t even know the HFS partition exists. At least Linux can see it.

fsck says everything’s okay. It mounts on other systems. I’m really confused. I’m starting to suspect the VFAT module might have a bug.

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 10:56 pm

Hurricane wrote: It mounts on Windows as well. So that just leaves Mint.

Of course, the HFS partition doesn’t mount, and I don’t expect it to. I’m only talking about the VFAT. Windows doesn’t even know the HFS partition exists. At least Linux can see it.

fsck says everything’s okay. It mounts on other systems. I’m really confused. I’m starting to suspect the VFAT module might have a bug.

I don’t think it’s wise to attempt to use large vfat partitions in linux

Also vfat is kernel built-in

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 11:31 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 11:44 pm

Okay. Figured out how to get the grub menu to show. Booted into the old 3.11 kernel that came stock with Mint. Everything works perfectly.

Thanks for all the help.

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 11:52 pm

So you have a custom kernel, but I don’t understand can’t get the grub menu to show

Did you remove the distro’s version

What I do is symlink the kernel and initrd so I can swap them if I have other versions.

Источник

0

2

mount: wrong fs type, bad option, bad superblock on /dev/sdb,
       missing codepage or helper program, or other error

fsck из util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block при попытке открыть /dev/sdb

The superблок could not be read or does not describe a valid ext2/ext3/ext4
ФС.  If the устройство is valid and it really contains an ext2/ext3/ext4
ФС (and not swap or ufs or something else), then the superблок
is corrupt, and you might try running e2fsck with an alternate superблок:
    e2fsck -b 8193 <устройство>
 or
    e2fsck -b 32768 <устройство>

One or more блок группа descriptor checksums are invalid.  Исправить? yes

группа descriptor 0 checksum is 0xc3d6, should be 0xf053.  ИСПРАВЛЕНО.
.................
и таких descriptor тысячи. 

группа descriptor 22356 checksum is 0x39be, should be 0x0a3b.  ИСПРАВЛЕНО.
Проход 1: Проверка inodes, блокs, а также размеров

0 Пользователей и 1 Гость просматривают эту тему.

Программа fsck (расшифровывается как File System Consistency Check) используется для проверки и восстановления одной или нескольких файловых систем Linux.

Эта проверка запускается автоматически во время загрузки при обнаружении несоответствий в файловой системе.

Также, при необходимости, она может быть запущена вручную.

Вы можете использовать команду fsck для восстановления поврежденных файловых систем, когда система не загружается, или раздел не может быть смонтирован, или если он стал доступен только для чтения.

В этой статье мы рассмотрим, как использовать команду ‘fsck’ или ‘e2fsck’ в Linux для восстановления поврежденной файловой системы.

🗂️ Что такое Ext2, Ext3 и Ext4 и как создавать и конвертировать файловые системы Linux

Примечание:

Выполняйте fsck на немонтированной файловой системе, чтобы избежать повреждения данных в ФС.

Для больших файловых систем выполнение fsck может занять много времени в зависимости от скорости системы и размера диска.

Когда проверка файловой системы завершена, fsck возвращает один из следующих кодов завершения:

Общий синтаксис:

fsck [option] [device or partition or mount point]

Повреждение файловой системы EXT4

Мы намеренно повредим файловую систему EXT4, выполнив приведенную ниже команду.

Она удаляет случайно выбранные блоки метаданных файловой системы

Примечание: Пожалуйста, не тестируйте это на производственном сервере, так как это может сильно повредить ваши данные.

sudo umount /data

Повреждение файловой системы ext4.

sudo dd if=/dev/zero of=/dev/sdb1 bs=10000 skip=0 count=1

1+0 records in
1+0 records out
10000 bytes (10 kB, 9.8 KiB) copied, 0.00394663 s, 2.5 MB/s

Когда вы попытаетесь загрузить файловую систему, вы увидите следующее сообщение об ошибке, поскольку она была повреждена.

sudo mount /data

mount: /data: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

Восстановление поврежденной файловой системы EXT4 и EXT3

Вы можете восстановить поврежденную файловую систему ext3 или ext4 в работающей системе Linux. fsck работает как обертка для команд fsck.ext3 и fsck.ext4.

Примечание: Если вы не можете размонтировать некоторые тома без рута из-за проблемы, загрузите систему в однопользовательский режим или режим rescue для восстановления.

Шаг-1: Размонтируйте устройство, на котором вы хотите запустить fsck.

sudo umount /dev/sdb1

Шаг-2: Запустите fsck для восстановления файловой системы:

sudo fsck.ext4 -p /dev/sdb1

-p : Автоматически устранить все проблемы, которые могут быть безопасно устранены без вмешательства пользователя.

Если вышеуказанный вариант не устраняет проблему, выполните команду fsck в следующем формате.

sudo fsck.ext4 -fvy /dev/sdb1

e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
Resize inode not valid.  Recreate? yes

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
Block bitmap differences:  -65536 -65538 -(65541--65542) -(65546--65547) -(65549--65550) -(65555--65557)
.
.
Fix? yes

Free inodes count wrong for group #0 (8181, counted=8165).
Fix? yes

Free inodes count wrong (327669, counted=327653).
Fix? yes

Padding at end of inode bitmap is not set. Fix? yes


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

          27 inodes used (0.01%, out of 327680)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 19
       43294 blocks used (3.30%, out of 1310464)
           0 bad blocks
           0 large files

          16 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
          18 files

Шаг-3: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /dev/sdb1

2) Восстановление тома LVM с помощью fsck

fsck можно запускать на логических томах LVM так же, как и на файловых системах стандартных разделов.

Для восстановления LVM-раздела следуйте приведенной ниже процедуре:

При необходимости вы также можете восстановить/восстановить том lvm вместо его ремонта.

Шаг-1: Убедитесь, что конкретный том LVM находится в активном состоянии для запуска fsck.

Чтобы проверить состояние LVM, выполните:

sudo lvscan

  inactive          '/dev/myvg/vol01' [1.00 GiB] inherit
  ACTIVE            '/dev/rhel/swap' [2.07 GiB] inherit
  ACTIVE            '/dev/rhel/root' [<26.93 GiB] inherit

Если он “inactive“, активируйте его, выполнив следующую команду.

sudo lvchange -ay /dev/myvg/vol01 -v

  Activating logical volume myvg/vol01.
  activation/volume_list configuration setting not defined: Checking only host tags for myvg/vol01.
  Creating myvg-vol01
  Loading table for myvg-vol01 (253:2).
  Resuming myvg-vol01 (253:2).

Шаг-2: Размонтируйте устройство или файловую систему, на которой вы хотите запустить fsck.

sudo umount /dev/myvg/vol01

Шаг-3: Запустите fsck для восстановления файловой системы.

Для запуска fsck необходимо ввести путь к LVM-тому, а не к реальному физическому разделу.

sudo fsck.ext4 -fvy /dev/myvg/vol01

e2fsck 1.45.6 (20-Mar-2020)
/dev/myvg/vol01: clean, 24/65536 files, 14094/262144 blocks

• -f : Принудительная проверка, даже если файловая система кажется чистой.
• -y : Предполагать ответ `yes’ на все вопросы; позволяет использовать e2fsck неинтерактивно.
• -v : Подробный режим

Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /apps

Заключение

В этом руководстве мы показали вам, как восстановить поврежденную файловую систему EXT4 в Linux.

Вы можете использовать ту же процедуру для EXT3 и других файловых систем.

Также мы показали, как запустить e2fsck на томах LVM.

Если у вас есть вопросы или замечания, не стесняйтесь оставлять комментарии.

см. также:

• 🐧 Как принудительно выполнить fsck при перезагрузке системы
• #️⃣ Как добавить зашифрованный жесткий диск на Linux
• 🛑 Команды Linux, которые вы никогда не должны запускать в своей системе
• 🐧 Советы по обеспечению безопасности сервера CentOS – часть 1
• 🐧 Проверка файловой системы Linux на наличие ошибок: команда FSCK с примерами
• 🐧 Как зашифровать каталоги с помощью eCryptfs на Linux

I want to mount a hard disk in remote debian server to retrieve some important data. The fdisk -l info of the disk :

Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd603e167

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdc1        2048 1953521663 1953519616 931.5G  6 FAT16

But when I try to mount it:

mount  /dev/sdc1 /back

I get this error:

mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

I have also tried

mount -t vfat  /dev/sdc1 /back

and

mount -t ext4  /dev/sdc1 /back

But they all give the same error.

Also,

fsck /dev/sdc1

yields:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
The filesystem size (according to the superblock) is 244190208 blocks
The physical size of the device is 244189952 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? 

How can I solve this?

Recently my Linux desktop computer can’t mount my 5TB external hard disk drive (HDD), and the file manager displays the “can’t read superblock” error on the screen. I’m going to share with you what I did to fix the error, so if you are in the same situation, this article may help you.

But before doing that, I want to explain some basic knowledge about hard disk drives and filesystems on Linux, so you will really know what you are doing. If you don’t care about those details, you can jump directly to the solution. A hard disk drive (HDD) is magnetic disk. A solid-state drive (SSD) is electronic disk.

The Structure of Hard Disk Drive

A hard disk drive usually has several circular platters stacked vertically with a spindle that rotates the disk in the center. Each platter is coated with a magnetizable material to record data. Each platter surface is divided into tens of thousands of tracks. It’s like running tracks in sports.

Hint: Hard disk drives are very complex devices and can be easily damaged if you drop them to the ground.

Each track is divided into sectors. There are typically hundreds of sectors per track and each sector usually has the same length. A sector is the smallest unit for reading data from the disk. That is to say, even if you just need a portion of the data from a sector, the read-write head will read the entire sector to retrieve the data. Traditionally one sector stores 512 bytes of data. In 2009 the industry devised the 4K sector size format known as the advanced format to improve disk reliability and increase capacity. After January 2011, most new hard drives store 4096 bytes of data in one sector.

Physical Sector Size vs Logical Sector Size

Although new hard drives use the 4K advanced format, operating systems still expect a 512 bytes sector size, so the firmware on the HDD divides a 4K physical sector into several logical sectors, typically 512 bytes. On Linux, you can check the physical sector size and logical sector size of an HDD with the fdisk command.

fdisk -l /dev/sda

You can see from the screenshot that the physical sector size of my hard disk is 4096 bytes and the logical sector size is 512 bytes. I/O size is the minimal chunks of data the operating system reads from a disk.

Partition Alignment

Using firmware to produce a logical sector can degrade performance, especially when file system partitions are not aligned with physical sectors. There are two requirements for partition alignment:

• The number of sectors on each partition must be in multiples of 8 because a physical sector contains 8 logical sectors.
• The start sector of each partition must be the first logical sector in a physical sector. Since sector 0 is the first sector of the entire disk, this means the start sector of each partition should be a multiple of 8, sector 0, sector 8, sector 16, etc.

When you create partitions on a hard disk drive, you should be aware of the following two partition tables.

• MBR: Master Boot Record.
• GPT: GUID Partition Table.

If you buy a new hard disk, it’s recommended to use the newer GPT format to partition your hard disk. Both MBR and GPT will use some sectors at the beginning of the disk, so you should leave some empty space (like 1MiB) before the first partition.  To create partitions that will be aligned with the physical sector, use sector as the unit when you partition your disk.

You can quickly check if your disk partitions are aligned with physical sectors with the parted (partition editor) utility. parted is a disk partition editor that supports multiple partition table formats, including MBR and GPT.

First, tell parted to use your disk. I use my/dev/sdb as an example.

parted /dev/sdb

Then type p to print the partition table on the disk. And run the following command to check partition alignment.

align-check opt partition-number

Type q to quit.

As you can see from the screenshot below, the first two partitions are not properly aligned. The third partition is aligned.

SSD Partition Alignment

Note that the structure of SSD is very different than that of an HDD. The smallest unit of an SSD module is called a cell. Consecutive cells form a page, many of which are organized into a block. Read and write operations are executed at the page level. The page size of an SSD varies from manufacturer to manufacturer and from model to model. There’s no straightforward way to check page size using the Linux command line, because the flash translation layer makes the OS think the SSD is a traditional hard disk. The OS doesn’t understand SSD pages and still uses sectors to describe locations on SSD.

Common page sizes are 8KiB, 16KiB, 32KiB. It’s also very important to have aligned partitions on SSD. If partitions are misaligned, then there will always be one extra page to read or write. Not only will it degrade performance, but also decreases the life span of SSD. To properly align partitions on SSD, all you need to do is to leave one empty page (e.g. 32KiB) at the start of SSD and make sure the size of every partition on SSD is multiples of the page size.

When you use GParted to create the first partition on SSD, it automatically leaves 1MiB empty space before the first partition, which is 32 empty pages (32 KiB * 32 = 1024 KiB). This is fine. The following screenshot shows creating an EFI system partition (ESP) for a UEFI computer. The partition size is 512MiB with a FAT32 file system.

Blocks in Filesystem

There’s a concept in filesystem called block, which is similar to a sector on disk drives. Many folks are confused by these two concepts. It’s not really that hard to understand the difference. When you create a partition on a disk, you can use sectors to define its size. If you format a partition with a file system, blocks will be created.

Operating system and file system access data on the disk in blocks rather than in sectors. A block is usually a multiple of sector. So why don’t we just access data in sectors? Well, the block can abstract away the physical details of the disk. If you address a sector (find out the address of a sector), you need to use the CHS scheme (cylinder-head-sector). This is because a hard disk drive has multiple platters. You need to know which platter and track the sector is located at. If you address a block, you just use block 0, block 1, block 2, etc, without having to know the physical details of the disk. Each block is mapped to a sector (or several sectors) with the logical block addressing (LBA) scheme.

Superblock

The first block of a disk or of a partition is called the superblock, and it’s the primary superblock. Superblock can be damaged like in a sudden power outage, so there are backup copies of the superblock in a block group.

• primary superblock
• backup superblock

Can’t read superblock

There can be several reasons why your OS can’t read the superblock on your HDD.

• The HDD is dropped to the ground and the superblock is damaged. This is usually physical damage to the corresponding sectors on the disk.
• There’s a sudden power outage. Because the superblock is cached in RAM, if a power outage happens, there might be important changes to the superblock that hasn’t been written to the disk.

If the primary superblock is damaged, you can’t mount the filesystem, and the operating system will probably tell you that it “can’t read superblock” if you try to mount the filesystem. We need to recover the bad superblock from backup copies. The following instructions show how to recover superblock for ext4 and Btrfs file system. My HDD is an external hard disk. If the damaged filesystem is your root file system, you need to boot your computer from a Linux Live USB stick.

Recover superblock on ext4 filesystem

Find out the device name of the damaged partition.

sudo parted -l

Determine the location of the backup superblocks.

sudo mke2fs -n /dev/xxx

For example, the device name of my HDD partition is /dev/sdb1, so I run

sudo mke2fs -n /dev/sdb1

It will tell you that the partition contains an ext4 file system, press y to continue. Don’t worry the -n option tells mke2fs not to create a file system.

mke2fs 1.45.5 (07-Jan-2020)
/dev/sdb1 contains a ext4 file system labelled 'Stretch'
	last mounted on /media/linuxbabe/b43e4eea-9796-4ac6-9c48-2bcaa46353732 on Thu Jan 28 02:43:43 2021
Proceed anyway? (y,N) y
Creating filesystem with 7864320 4k blocks and 1966080 inodes
Filesystem UUID: fcae3dc8-ee11-412c-97f0-27106601314e
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000

At the bottom, you can see the location of backup superblocks. Next, restore the superblock from the first backup copy.

sudo e2fsck -b 32768 /dev/xxx

Now you should be able to mount your ext4 partition.

Recover superblock on btrfs filesystem

Find out the device name of the damaged partition.

sudo parted -l

Install a Btrfs utility.

sudo apt install btrfs-progs

Then run the following command to recover superblock.

sudo btrfs rescue super-recover -v /dev/xxx

If it tells you “All supers are valid, no need to recover”, then check the syslog.

sudo dmesg

You might find the following message, which indicates the log tree is corrupted, so it can’t replay the log.

BTRFS: error (device sdb1) in btrfs_run_delayed_refs:2227: errno=-5 IO failure
BTRFS: error (device sdb1) in btrfs_replay_log:2287: errno=-5 IO failure (Failed to recover log tree)

Then you need to run the following command to clear the filesystem log tree.

sudo btrfs rescue zero-log /dev/xxx

Now you should be able to mount your Btrfs file system.

If there’s periodic IO failure for your Btrfs file system, you can add a crontab job to automatically clear the file system log tree once a day.

sudo crontab -e

Add the following line at the end of the crontab file.

@daily umount /dev/xxx && btrfs rescue zero-log /dev/xxx && mount -a

Save and close the file.

Backing Up Files on your Disk

To prevent data loss, it’s recommended to use a tool like Duplicati to automatically back up your files to cloud storage. Duplicati will encrypt your files to prevent prying eyes.

• How to Use Duplicati to Back Up Files on Debian, Ubuntu, Linux Mint

External HDD becomes Read-only?

Sometimes there can be error in the file system so Linux can only mount the external HDD in read-only mode. To fix it, you need to unmount the external HDD, then use the e2fsck command-line utility to fix the file system errors.

For example,

sudo e2fsck /dev/sdb1

then answer y to optimize or fix the file system, and you will be able to mount the external HDD in writable mode.

Tip

• Some motherboards can still charge USB devices when you shut down the operating system. If you have an external HDD, it’s recommended to turn off electricity for USB devices when shut down, so your external HDD can stop spinning. This is good for its life span. For example, I have an ASUS PRIME z270 motherboard. I go to the UEFI advanced settings section and disable “charging USB devices in power state s5”.

Wrapping Up

I hope this tutorial helped you fix the “can not read superblock” error on Linux. As always, if you found this post useful, then subscribe to our free newsletter to get more tips and tricks. Take care 🙂