mysql磁盘无法挂载,挂载硬盘报错无法挂载

解决方案：这种情况一般为superblock损坏的概率很大。

superblock是什么？

分区的第一块superblock位于分区的第二块block。

如果分区的blocksize是1024，则superblock位于[1024,204之间。

ext2文件系统的结构请参考这个网站，写的非常清楚：

http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

这个是superblock的结构，摘自：

http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

继续刚才的话题。我/dev/sdb1挂载不上了。

所以我做了如下操作：

[root@dhcp-0-142~]# dumpe2fs /dev/sdb1

dumpe2fs1.39 (29-May-2006)

Filesystemvolume name:

Lastmounted on:

FilesystemUUID:  c3800df3-5c34-4b53-8144-94029b5736d8

Filesystemmagic number: 0xEF53

Filesystemrevision #:  1 (dynamic)

Filesystemfeatures:  has_journal

resize_inode dir_index filetypesparse_super

Defaultmount options:  (none)

Filesystemstate:  clean

with errors

Errorsbehavior:  Continue

FilesystemOS type:  Linux

Inodecount:  0

Blockcount:  0

Reservedblock count:  0

Freeblocks:  20926971

Freeinodes:  4705752

Firstblock:  1

Blocksize:  1024

Fragmentsize:  1024

ReservedGDT blocks:  256

Blocksper group:  8192

Fragmentsper group:  8192

Inodesper group:  2008

Inodeblocks per group:  251

Filesystemcreated:  Tue

Oct 7 19:18:08 2008

Lastmount time:  n/a

Lastwrite time:  Tue Oct

7 19:29:39 2008

Mountcount:  0

Maximummount count:  20

Lastchecked:  Tue Oct 7 19:18:08 2008

Checkinterval:  15552000 (6 months)

Nextcheck after:  Sun Apr

5 19:18:08 2009

Reservedblocks uid:  0 (user root)

Reservedblocks gid:  0 (group root)

Firstinode:  11

Inodesize:  128

Journalinode:  8

Defaultdirectory hash:  tea

DirectoryHash Seed:  7f7e1c41-5cae-4f23-9873-877991751ccb

Journalbackup:  inode blocks

dumpe2fs:Illegal inode number while reading journal

inode

[root@dhcp-0-142~]#

根据Blocksper group:  8192的信息，我定位了第一个备份superblock的位置为8193。

所以我做如下操作：

[root@dhcp-0-142~]# fsck -b 8193 /dev/sdb1

fsck1.39 (29-May-2006)

e2fsck1.39 (29-May-2006)

/dev/sdb1was not cleanly unmounted, check forced.

Pass1: Checking inodes, blocks, and sizes

Pass2: Checking directory structure

Pass3: Checking directory connectivity

Pass4: Checking reference counts

Pass5: Checking group summary information

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

/dev/sdb1:11/26104 files (9.1% non-contiguous), 8966/104388

blocks

[root@dhcp-0-142~]# mount /dev/sdb1 /mnt/sdb1

[root@dhcp-0-142~]# ls /mnt/sdb1

lost+found

[root@dhcp-0-142~]#

superblock已经修复，文件系统挂载正常。

之所以这么做，是有依据的。

ext2/3文件系统在创建文件系统的时候会创建若干个superblock的备份存放于特定位置。

[root@dhcp-0-142~]# dumpe2fs /dev/sdb1 | grep

--before-context=1 superblock

dumpe2fs1.39 (29-May-2006)

Group0: (Blocks 1-8192)

Primarysuperblock at 1, Group descriptors at 2-2

--

Group1: (Blocks 8193-16384)

Backupsuperblock at 8193, Group descriptors at 8194-8194

--

Group3: (Blocks 24577-3276

Backupsuperblock at 24577, Group descriptors at

24578-24578

--

Group5: (Blocks 40961-49152)

Backupsuperblock at 40961, Group descriptors at

40962-40962

--

Group7: (Blocks 57345-65536)

Backupsuperblock at 57345, Group descriptors at

57346-57346

--

Group9: (Blocks 73729-81920)

Backupsuperblock at 73729, Group descriptors at

73730-73730

[root@dhcp-0-142~]#

从上面操作可以看出，在第1、3、4、7、9这几个BlockGroup上存放有superblock备份。

什么是BlockGroup？ext2/3文件系统为了提高磁盘寻道效率，把inodetable等信息按照Inodesper

group分成若干组存放，而没有全部放在一起。

此图摘自：http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

Inodesper group信息相见命令：

[root@dhcp-0-142~]# dumpe2fs /dev/sdb1 | grep

'Inodes per group'

dumpe2fs1.39 (29-May-2006)

Inodesper group:  2008

[root@dhcp-0-142~]#

有些文件系统superblock损坏的很厉害。连dumpe2fs和tune2fs都看不到信息。[root@dhcp-0-175~]#

dd if=/dev/zero of=/dev/sdb1 bs=1 count=1024 seek=1024

1024+0records in

1024+0records out

1024bytes (1.0 kB) copied, 0.0228272 seconds, 44.9 kB/s

[root@dhcp-0-175~]# dumpe2fs /dev/sdb1

dumpe2fs1.39 (29-May-2006)

dumpe2fs:Bad magic number in super-block while trying to open

/dev/sdb1

Couldn'tfind valid filesystem

superblock.

[root@dhcp-0-175~]# tune2fs -l /dev/sdb1

tune2fs1.39 (29-May-2006)

tune2fs:Bad magic number in super-block while trying to open

/dev/sdb1

Couldn'tfind valid filesystem

superblock.

[root@dhcp-0-175~]#

这时候我们根本无法从dumpe2fs和tune2fs看到Backupsuperblock的位置。

我们可以尝试从superblock的结构来猜测superblock的位置(superblock结构见上图)。

我们从superblock结构可以知道，卷标volumename存放于superblock中。所以如果文件系统有设置卷标，那么我们可以尝试从卷标来定位superblock。

我们用hexdump把文件系统dump出来：

[root@dhcp-0-175~]# hexdump -C /dev/sdb1 >

/var/sdb1.hexdump

[root@dhcp-0-175~]#

我们已知/dev/sdb1的卷标是sdb1(如果不知道卷标或者没有设置卷标，那么我就没办法了)。

我们搜索sdb1，搜到结果如下：

我们猜测这里就是备份superblock的位置。

卷标起始位置是0x18000078。由于superblock结构里volumename位于0x78的位置，所以我们可以猜测备份superblock的起始位置是0x18000078–

0x78 = 0x18000000。

由于blocksize位于superblock的[0x18,0x22)的位置，这里的值是0x0002，得出blocksize是0x0400x

( 0x00020x0002 ) = 0x1000 = 4096

( [0x18, 0x22) 处值n和blocksize的关系是blocksize = 0x0400 x

0x0002n，此公式感谢得新倾情赞助)

而备份superblock的偏移量为offset/ blocksize，即0x18000000/ 0x1000 =

0x00018000 = 98304。

因此我们执行：

[root@dhcp-0-175~]# fsck.ext3 -b 98304 /dev/sdb1

e2fsck1.39 (29-May-2006)

sdb1was not cleanly unmounted, check forced.

Pass1: Checking inodes, blocks, and sizes

Pass2: Checking directory structure

Pass3: Checking directory connectivity

Pass4: Checking reference counts

Pass5: Checking group summary information

sdb1:***** FILE SYSTEM WAS MODIFIED *****

sdb1:11/123648 files (9.1% non-contiguous), 8298/246991

blocks

[root@dhcp-0-175~]#

这样文件系统就有给修复的可能性了。

测试一下：

[root@dhcp-0-175~]# dumpe2fs /dev/sdb1

dumpe2fs1.39 (29-May-2006)

Filesystemvolume name:  sdb1

Lastmounted on:

FilesystemUUID:  0293bd85-b911-43bf-853e-6588b3eaaf39

Filesystemmagic number: 0xEF53

Filesystemrevision #:  1 (dynamic)

Filesystemfeatures:  has_journal

resize_inode dir_index filetypesparse_super large_file

Defaultmount options:  (none)

Filesystemstate:  clean

Errorsbehavior:  Continue

FilesystemOS type:  Linux

Inodecount:  123648

Blockcount:  246991

Reservedblock count:  12349

Freeblocks:  238693

Freeinodes:  123637

Firstblock:  0

Blocksize:  4096

Fragmentsize:  4096

ReservedGDT blocks:  60

Blocksper group:  32768

Fragmentsper group:  32768

Inodesper group:  15456

Inodeblocks per group:  483

Filesystemcreated:  Wed

Oct 8 12:49:09 2008

Lastmount time:  n/a

Lastwrite time:  Wed Oct

8 12:52:10 2008

Mountcount:  0

Maximummount count:  28

Lastchecked:  Wed Oct 8 12:52:10 2008

Checkinterval:  15552000 (6 months)

Nextcheck after:  Mon Apr

6 12:52:10 2009

Reservedblocks uid:  0 (user root)

Reservedblocks gid:  0 (group root)

Firstinode:  11

Inodesize:  128

Journalinode:  8

Defaultdirectory hash:  tea

DirectoryHash Seed:  2efa124c-dde6-4046-9181-a05b7e6d182a

Journalbackup:  inode blocks

Journalsize:  16M

Group0: (Blocks 0-32767)

Primarysuperblock at 0, Group descriptors at 1-1

ReservedGDT blocks at 2-61

Blockbitmap at 62 (+62), Inode bitmap at 63 (+63)

Inodetable at 64-546 (+64)

28113free blocks, 15445 free inodes, 2 directories

Freeblocks: 4655-32767

Freeinodes: 12-15456

Group1: (Blocks 32768-65535)

Backupsuperblock at 32768, Group descriptors at

32769-32769

ReservedGDT blocks at 32770-32829

Blockbitmap at 32830 (+62), Inode bitmap at 32831 (+63)

Inodetable at 32832-33314 (+64)

32221free blocks, 15456 free inodes, 0 directories

Freeblocks: 33315-65535

Freeinodes: 15457-30912

Group2: (Blocks 65536-98303)

Blockbitmap at 65536 (+0), Inode bitmap at 65537 (+1)

Inodetable at 65538-66020 (+2)

32283free blocks, 15456 free inodes, 0 directories

Freeblocks: 66021-98303

Freeinodes: 30913-46368

Group3: (Blocks 98304-131071)

Backupsuperblock at 98304, Group descriptors at

98305-98305

ReservedGDT blocks at 98306-98365

Blockbitmap at 98366 (+62), Inode bitmap at 98367 (+63)

Inodetable at 98368-98850 (+64)

32221free blocks, 15456 free inodes, 0 directories

Freeblocks: 98851-131071

Freeinodes: 46369-61824

Group4: (Blocks 131072-163839)

Blockbitmap at 131072 (+0), Inode bitmap at 131073 (+1)

Inodetable at 131074-131556 (+2)

32283free blocks, 15456 free inodes, 0 directories

Freeblocks: 131557-163839

Freeinodes: 61825-77280

Group5: (Blocks 163840-196607)

Backupsuperblock at 163840, Group descriptors at

163841-163841

ReservedGDT blocks at 163842-163901

Blockbitmap at 163902 (+62), Inode bitmap at 163903

(+63)

Inodetable at 163904-164386 (+64)

32221free blocks, 15456 free inodes, 0 directories

Freeblocks: 164387-196607

Freeinodes: 77281-92736

Group6: (Blocks 196608-229375)

Blockbitmap at 196608 (+0), Inode bitmap at 196609 (+1)

Inodetable at 196610-197092 (+2)

32283free blocks, 15456 free inodes, 0 directories

Freeblocks: 197093-229375

Freeinodes: 92737-108192

Group7: (Blocks 229376-246990)

Backupsuperblock at 229376, Group descriptors at

229377-229377

ReservedGDT blocks at 229378-229437

Blockbitmap at 229438 (+62), Inode bitmap at 229439

(+63)

Inodetable at 229440-229922 (+64)

17068free blocks, 15456 free inodes, 0 directories

Freeblocks: 229923-246990

Freeinodes: 108193-123648

[root@dhcp-0-175~]# mount /dev/sdb1 /mnt

[root@dhcp-0-175~]# ls /mnt

lost+found

[root@dhcp-0-175~]#

看来我运气很好。文件系统成功修复。