SuperBlock损坏修复

   源地址:http://blog.sina.com.cn/s/blog_709df8c80100ldup.html

什么是superblock?

可以参考下这个网站:http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

详细的介绍superblock组成 构成

 

大家可能遇到过这样的情况:

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

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

[root@dhcp-0-142 ~]#

 

这种情况一般为superblock损坏的概率很大。

 

例如我现在/dev/sdb1无法挂载 现象如上,可以这样操作:

 

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

dumpe2fs 1.39 (29-May-2006)

Filesystem volume name: <none>

Last mounted on: <not available>

Filesystem UUID: c3800df3-5c34-4b53-8144-94029b5736d8

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal resize_inode dir_index filetype sparse_super

Default mount options: (none)

Filesystem state: clean with errors

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 0

Block count: 0

Reserved block count: 0

Free blocks: 20926971

Free inodes: 4705752

First block: 1

Block size: 1024

Fragment size: 1024

Reserved GDT blocks: 256

Blocks per group: 8192

Fragments per group: 8192

Inodes per group: 2008

Inode blocks per group: 251

Filesystem created: Tue Oct 7 19:18:08 2008

Last mount time: n/a

Last write time: Tue Oct 7 19:29:39 2008

Mount count: 0

Maximum mount count: 20

Last checked: Tue Oct 7 19:18:08 2008

Check interval: 15552000 (6 months)

Next check after: Sun Apr 5 19:18:08 2009

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 128

Journal inode: 8

Default directory hash: tea

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

Journal backup: inode blocks

dumpe2fs: Illegal inode number while reading journal inode

[root@dhcp-0-142 ~]#

所以我做如下操作:

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

fsck 1.39 (29-May-2006)

e2fsck 1.39 (29-May-2006)

/dev/sdb1 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/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

dumpe2fs 1.39 (29-May-2006)

Group 0: (Blocks 1-8192)

Primary superblock at 1, Group descriptors at 2-2

--

Group 1: (Blocks 8193-16384)

Backup superblock at 8193, Group descriptors at 8194-8194

--

Group 3: (Blocks 24577-32768)

Backup superblock at 24577, Group descriptors at 24578-24578

--

Group 5: (Blocks 40961-49152)

Backup superblock at 40961, Group descriptors at 40962-40962

--

Group 7: (Blocks 57345-65536)

Backup superblock at 57345, Group descriptors at 57346-57346

--

Group 9: (Blocks 73729-81920)

Backup superblock at 73729, Group descriptors at 73730-73730

[root@dhcp-0-142 ~]#

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

什么是Block Group?ext2/3文件系统为了提高磁盘寻道效率,把inode table等信息按照Inodes per group分成若干组存放,而没有全部放在一起。 
 

Inodes per group信息相见命令:

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

dumpe2fs 1.39 (29-May-2006)

Inodes per 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+0 records in

1024+0 records out

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

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

dumpe2fs 1.39 (29-May-2006)

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

Couldn't find valid filesystem superblock.

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

tune2fs 1.39 (29-May-2006)

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

Couldn't find valid filesystem superblock.

[root@dhcp-0-175 ~]#

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

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

我们从superblock结构可以知道,卷标volume name存放于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结构里volume name位于0x78的位置,所以我们可以猜测备份superblock的起始位置是0x18000078 – 0x78 = 0x18000000。

由于blocksize位于superblock的[0x18, 0x22)的位置,这里的值是0x0002,得出blocksize是0x0400 x ( 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

e2fsck 1.39 (29-May-2006)

sdb1 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

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

dumpe2fs 1.39 (29-May-2006)

Filesystem volume name: sdb1

Last mounted on: <not available>

Filesystem UUID: 0293bd85-b911-43bf-853e-6588b3eaaf39

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file

Default mount options: (none)

Filesystem state: clean

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 123648

Block count: 246991

Reserved block count: 12349

Free blocks: 238693

Free inodes: 123637

First block: 0

Block size: 4096

Fragment size: 4096

Reserved GDT blocks: 60

Blocks per group: 32768

Fragments per group: 32768

Inodes per group: 15456

Inode blocks per group: 483

Filesystem created: Wed Oct 8 12:49:09 2008

Last mount time: n/a

Last write time: Wed Oct 8 12:52:10 2008

Mount count: 0

Maximum mount count: 28

Last checked: Wed Oct 8 12:52:10 2008

Check interval: 15552000 (6 months)

Next check after: Mon Apr 6 12:52:10 2009

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 128

Journal inode: 8

Default directory hash: tea

Directory Hash Seed: 2efa124c-dde6-4046-9181-a05b7e6d182a

Journal backup: inode blocks

Journal size: 16M 

 Group 0: (Blocks 0-32767)

Primary superblock at 0, Group descriptors at 1-1

Reserved GDT blocks at 2-61

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

Inode table at 64-546 (+64)

28113 free blocks, 15445 free inodes, 2 directories

Free blocks: 4655-32767

Free inodes: 12-15456

Group 1: (Blocks 32768-65535)

Backup superblock at 32768, Group descriptors at 32769-32769

Reserved GDT blocks at 32770-32829

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

Inode table at 32832-33314 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 33315-65535

Free inodes: 15457-30912

Group 2: (Blocks 65536-98303)

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

Inode table at 65538-66020 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 66021-98303

Free inodes: 30913-46368

Group 3: (Blocks 98304-131071)

Backup superblock at 98304, Group descriptors at 98305-98305

Reserved GDT blocks at 98306-98365

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

Inode table at 98368-98850 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 98851-131071

Free inodes: 46369-61824

Group 4: (Blocks 131072-163839)

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

Inode table at 131074-131556 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 131557-163839

Free inodes: 61825-77280

Group 5: (Blocks 163840-196607)

Backup superblock at 163840, Group descriptors at 163841-163841

Reserved GDT blocks at 163842-163901

Block bitmap at 163902 (+62), Inode bitmap at 163903 (+63)

Inode table at 163904-164386 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 164387-196607

Free inodes: 77281-92736

Group 6: (Blocks 196608-229375)

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

Inode table at 196610-197092 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 197093-229375

Free inodes: 92737-108192

Group 7: (Blocks 229376-246990)

Backup superblock at 229376, Group descriptors at 229377-229377

Reserved GDT blocks at 229378-229437

Block bitmap at 229438 (+62), Inode bitmap at 229439 (+63)

Inode table at 229440-229922 (+64)

17068 free blocks, 15456 free inodes, 0 directories

Free blocks: 229923-246990

Free inodes: 108193-123648

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

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

lost+found

[root@dhcp-0-175 ~]#

其实对于这种superblock破坏很严重的文件系统,其实系统已经有了很强大的修复方案:
我们可以用mke2fs -S 来修复superblock。

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

mount: you must specify the filesystem type

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

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

[root@dhcp-0-175 /]# mke2fs -S /dev/sdb1

mke2fs 1.39 (29-May-2006)

Filesystem label=

OS type: Linux

Block size=1024 (log=0)

Fragment size=1024 (log=0)

24480 inodes, 97656 blocks

4882 blocks (5.00%) reserved for the super user

First data block=1

Maximum filesystem blocks=67371008

12 block groups

8192 blocks per group, 8192 fragments per group

2040 inodes per group

Superblock backups stored on blocks:

8193, 24577, 40961, 57345, 73729

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

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

[root@dhcp-0-175 /]# cd /mnt

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

file0 file14 file20 file27 file33 file4 file46 file52 file59 file65 file71 file78 file84 file90 file97

file1 file15 file21 file28 file34 file40 file47 file53 file6 file66 file72 file79 file85 file91 file98

file10 file16 file22 file29 file35 file41 file48 file54 file60 file67 file73 file8 file86 file92 file99

file100 file17 file23 file3 file36 file42 file49 file55 file61 file68 file74 file80 file87 file93 lost+found

file11 file18 file24 file30 file37 file43 file5 file56 file62 file69 file75 file81 file88 file94

file12 file19 file25 file31 file38 file44 file50 file57 file63 file7 file76 file82 file89 file95

file13 file2 file26 file32 file39 file45 file51 file58 file64 file70 file77 file83 file9 file96

[root@dhcp-0-175 mnt]#

 

e2fsck也可以达到同样的效果

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

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

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

e2fsck 1.39 (29-May-2006)

Couldn't find ext2 superblock, trying backup blocks...

/dev/sdb1 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

Free blocks count wrong for group #0 (3549, counted=3547).

Fix<y>? yes

Free blocks count wrong (88895, counted=88893).

Fix<y>? yes

Free inodes count wrong for group #0 (2029, counted=1929).

Fix<y>? yes

Free inodes count wrong (24469, counted=24369).

Fix<y>? yes

 

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

/dev/sdb1: 111/24480 files (1.8% non-contiguous), 8763/97656 blocks

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

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

file0 file15 file21 file28 file34 file40 file47 file53 file6 file66 file72 file79 file85 file91 file98

file1 file16 file22 file29 file35 file41 file48 file54 file60 file67 file73 file8 file86 file92 file99

file10 file17 file23 file3 file36 file42 file49 file55 file61 file68 file74 file80 file87 file93 lost+found

file11 file18 file24 file30 file37 file43 file5 file56 file62 file69 file75 file81 file88 file94

file12 file19 file25 file31 file38 file44 file50 file57 file63 file7 file76 file82 file89 file95

file13 file2 file26 file32 file39 file45 file51 file58 file64 file70 file77 file83 file9 file96

file14 file20 file27 file33 file4 file46 file52 file59 file65 file71 file78 file84 file90 file97

[root@dhcp-0-175 /]# 

 

当你的系统出现superblock corrupt而无法启动时:

1.用应急盘启动,先看fdisk的结果.如果你的分区表看起来正常,那么恢复的可能性就比较大,如果出现cannot open /dev/sda2的提示,那么想一想你的scsi卡启动没有,如果没有,那么你可以试着用小红帽的安装光盘启动,记住,仅仅是看分区表,千万不要写它.然后把分区情况详细记录下来.

 

2.试着e2fsck /dev/hda2,(先不要加-p -y 之类的参数,)用手动进行修复,同时也可以了解具体是文件系统的那些地方损坏了,如果你的运气好,e2fsck过去了,/dev/hda2已经基本修复,当然修复的可能是99.9%,也可能是99%这就看文件系统的损坏程度乐,不过现在可以说你的数据已经都找回来了.剩下的事就是mount上把数据备份出来以防万一.

 

3.如果e2fsck没过去(确保你的硬盘已经正确驱动乐),也不要着急,因为superblock在硬盘中有很多地方有备份,现在你最好把硬盘卸下来挂到另一个好的linux系统上,当然同样要保证硬盘被正确驱动乐.先用e2fsck /dev/hda2,如果结果和前面一样,就用e2fsck -b xxx -f /dev/hda2, xxx是硬盘上superblock的备份块,xxx=n*8192+1,n=1,2,3...一般来讲,如果系统瘫痪的真正原因是superblock损坏,这种办法就应该可以恢复你的数据了。如果执行后的结果还是不能通过,那么往下一步.

 

4.利用dd命令.先dd if=/dev/hda2 of=/tmp/rescue conv=noerror(/tmp/rescue是一个文件),把重要的数据拷出来,当然,这个盘要比你损坏的盘大一点,否则拷不下.另外,上面的dd命令在不同的境况下if和of应作相应的修改,写在这里只是一个例子,总之在用dd之前最好先看看man.刚才你已经看到你的分区表了,现在找一个和你的硬盘一样的硬盘,应该是一摸一样(大小,型号),在这块硬盘上按照坏盘上的分区表分区,分的区也应该是也是一模一样然后用dd命令把坏盘上superblock location后的东东全部拷到好盘的superblock location后,上帝保佑你,当你再次启动系统时就可以看到熟悉的数据了,有人用这种方法恢复了99%以上的数据,不过好在这种方法(包括前面的方法)没有动那块坏盘上的数据,如果还是没有恢复,那没你还有最后一种选择.

 

5. 在手册页里称这种方法为last-ditch recovery method,就是说这是最后的恢复方法,只有当你已经尝试了其他的方法,都没有能恢复你的数据的情况下才用,因为这需要冒一定的风险.
把你的硬盘挂在一台好的linux box上,运行:#mke2fs -S /dev/hda2(如果你的数据在hda2里)这条命令只重建superblock,而不碰inode表,不过这仍有一定的风险。good luck to you all.当时也有人建议我如果实在不行的话就重装系统(不动分区也不格式化),这也可能有效,但你也应该清楚这种方法就像mke2fs -S /dev/hd*一样是有风险的。

一点建议:
如果你的硬盘不是可以轻易就重做的,最好在建立一个新的系统后:

1。拿出笔和纸,把你的分区信息详细记录下来.

2. 用mkbootdisk做好现在这个系统的启动盘并测试.特别是如果你用的硬盘是scsi的。

3. 在用mke2fs建立一个文件系统后将屏幕上的superblock所在位置记录下来。

4. 用crontab对重要数据进行备份。ext2文件系统(包括其他的unix文件系统)是很强壮的,但你仍然应该小心。

 

 

RedHat官方解释:

解决方法:

通常在作磁盘操作之前应该备份磁盘的数据,在作这个操作之前也应该把磁盘上的所有内容备份到另一个磁盘中。就是说如果这个故障盘是20g的话,就需要一个20G的备份空间。备份的命令如下:

#dd if=/dev/baddrive of=/storagearea
然后可以在已经卸载的故障盘上运行如下命令找到备份的superblock.

#mke2fs -n /dev/badparition
再运行mke2fs命令的时候需要把参数设置成为文件系统创建时所用的参数。如果当初使用的是默认值, 那就可以使用如下命令:

#mke2fs -n -b 4000 /dev/hdb1
可以看到有如下的输出:

Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
122400 inodes, 488848 blocks
24442 blocks (5.00%) reserved for the super user
First data block=1
60 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
从输出可知superblock存在于: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

时间: 2024-11-01 17:51:38

SuperBlock损坏修复的相关文章

记一次 superblock 损坏导致服务器无法启动的故障修复

原文地址:http://www.cppblog.com/dancefire/archive/2011/03/09/fix-bad-superblock-in-linux.html 前几天接到朋友联系,说他的服务器坏了,启动不起来了.这是一个RHEL 4的服务器,而且是那种盗版RHEL 4,也就是说没有售后服务的,联系我问问能不能帮帮忙.我也很久没有弄过Linux系统上的东西了.只好尝试一下,庆幸的是,修好了,并帮朋友维护了一段时间,在此记录一些修复和维护中碰到的问题.修复 superblock

Win7系统怎么无法开机引导损坏修复

  Win7系统怎么无法开机引导损坏修复?Win7自从诞生以来就受到了众多的好评,不过也有一些不少的差评存在噢,而导致差评的原因也是因为Win7发生的系统故障难题.比如有小伙伴遇到了无法开机,而且引导损坏的情况,那么要怎么解决呢?下面就让小编来告诉大家. Win7系统修复步骤: 1.将事先已经制作好U盘PE系统的U盘插入电脑,然后关机. 2.开机进入BIOS界面,设置U盘优先启动(或按下启动项选项键,选择U盘启动),进入PE后,回车. 3.进入PE系统桌面后,打开Windows启动引导修复工具.

excel打不开提示文档已损坏修复教程

文档已损坏修复教程-文档损坏打不开怎么办"> 1.我们打开excel 文件会提示文件提示损坏,然后进入excel会发现文件是空白程序界面. 2.好我们现在不关excel点击空白程序左上角点击文件按钮,如下图所示 3.然后在菜单中我们点击选项,如下图所示 4.然后在如图所示我们点击"信任中心",如下图所示 5.然后我们再找到"信任中心"具体如下. 6.在进入到"信任中心设置"我们找到"受保护的视图"细节如下图所示

Word文档损坏修复的几种实用方法

Word 文档是许多电脑用户写作时使用的文件格式,当您辛辛苦苦写完一篇Word文档后,发现它因损坏而无法打开时,一定非常着急.其实,您不必心焦,因为我们还是有一些方法可以修复损坏文档,恢复受损文档中的文字.下面是具体的步骤. Word修复工具(修复出错遇到问题需要关闭) V1.0 中文绿色版 1 采用专用修复功能 ①在"文件"菜单上,单击"打开". ②在"查找范围"列表中,单击包含要打开的文件的驱动器.文件夹或Internet 位置. ③在文件夹

MySQL数据库INNODB表损坏修复处理过程分享_Mysql

突然收到MySQL报警,从库的数据库挂了,一直在不停的重启,打开错误日志,发现有张表坏了.innodb表损坏不能通过repair table 等修复myisam的命令操作.现在记录下解决过程,下次遇到就不会这么手忙脚乱了. 处理过程: 一遇到报警之后,直接打开错误日志,里面的信息: InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 30506. InnoDB: You may have t

移动硬盘打不开怎么修复 修复损坏的移动硬盘方法

移动硬盘打不开原因: 1)数据线问题:换个数据线试试 2)USB接口供电不足:换个USB插口 3)移动硬盘软件问题:突然插拔.死机.编辑,拷贝文件时卡住很容易造成分区表部分损坏,就会出现提示格式化等问题.而其中的FAT表损坏的话,就会出现文件乱码或是打不开等情况. 4)硬件问题:移动硬盘本身有坏块,或是存储芯片接触不良,都会出现提示格式化等问题. 对于移动硬盘打不开问题,用户可以自行尝试以下方法进行修复,不过该方法并不能保证一定解决故障问题. 文件或目录损坏修复1 1.双击盘符后提示文件或目录损

1108File Space Bitmap Block损坏能修复吗2

[20161108]File Space Bitmap Block损坏能修复吗? --这阵子做了数据文件的一些探究,还是回到File Space Bitmap Block损坏修复的问题. --链接http://www.itpub.net/thread-2071023-1-1.html提到File Space Bitmap Block损坏,问能修复吗? --通过我前面的测试,可以把空间设置为1.这样就可以解决这个问题,问题在在于相应的数据块如何构造. --实际上很简单我仅仅建立1个相同大小的数据文

Linux 文件系统的 Superblock, Inode, Dentry 和 File

参考文档:http://www.elmerzhang.com/2012/12/suerblock-inode-dentry-file-of-filesystem/ http://www.360doc.com/content/12/0322/14/6702151_196616602.shtml http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm http://blog.csdn.net/poechant/article/detail

xp系统在把文件删除到回收站的时候提示回收站已损坏

在系统中我们难免会删除一些没用的文件,而通常没用的文件会自动放到回收站里面,有的时候放在回收站里面的文件你会突然发现有用,然后可以去找回来,很简单.而当提示你回收站损坏的时候,我们肯定要解决这个问题. 1 回收站损坏修复的原理: 回收站是系统默认的一个功能,当电脑开机的时候,如果检查不到你电脑里面有回收站的功能,那么会自动修复该功能.也就是你只要删除该功能,电脑下次开机会自动回复该功能,到电脑刚刚装机状态. 2 解决方法 进入命令提示符窗口,点击开始 - 运行 - 输入cmd,回车即可进入. 3