• 挂载硬盘报错无法挂载


    挂载硬盘报错无法挂载:# mount /dev/sdb1 /mnt/sdb1

    mount:wrong fs type, bad option, bad superblock on /dev/sdb1,
      missingcodepage or other error
      Insome cases useful info is found in syslog - try
      dmesg| tail or so
    解决方案:这种情况一般为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~]#
     
  • 相关阅读:
    Django和flask中使用原生SQL方法
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in
    Docker常用命令
    MySQL的压力测试
    使用docker-compose快速搭建PHP开发环境
    Docke如何配置Nginx和PHP
    Docker容器的重命名和自动重启
    docker部署MySQL、Redis和Nginx
    docker-compose的安装卸载以及如何使用
    docker如何制作自己的镜像
  • 原文地址:https://www.cnblogs.com/yanzhi123/p/3061136.html
Copyright © 2020-2023  润新知