一例Ext4文件系统fsck后损坏的修复过程
嵌入式系统文件系统损坏解决方案
嵌入式系统文件系统损坏解决方案下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。
文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor.I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!嵌入式系统文件系统损坏的解决方案嵌入式系统在我们的日常生活中无处不在，从智能手机到智能家居，从汽车导航到医疗设备，它们都依赖于稳定的文件系统来存储和管理数据。
Ext4文件系统修复
Ext4⽂件系统修复Ext4⽂件系统修复⽬录⼀、super block硬盘分区开头、开头的第⼀个byte是byte0，从byte1024开始往后的⼀部分数据。
由于block size最⼩时1024bytes，所以superblock在block1中（此时block的⼤⼩正好是1024bytes），也可能是在block 0中。
超级块保存了⽂件系统设定的⽂件块⼤⼩、操作函数、inode链表等重要信息。
⼆、查看分区设备信息⼀般情况下我们是能够通过⼀些命令查看到分区的⼀些信息，如果super block有损坏，则该分区设备则不能够正常使⽤，还有可能不能通过命令查看设备分区的信息。
命令：dumpe2fs /dev/sdb1tune2fs -h /dev/sdb1linux-iu82:/ # dumpe2fs -h /dev/sdb1dumpe2fs 1.43.8 (1-Jan-2018)Filesystem volume name: <none> #⽂件系统的名称Last mounted on: /a #是否挂载及挂载点Filesystem UUID: cd22c2f7-d461-4cbe-973b-16d0b584a7b2Filesystem magic number: 0xEF53Filesystem revision #: 1 (dynamic)Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isizeFilesystem flags: signed_directory_hashDefault mount options: user_xattr aclFilesystem state: clean #正常，异常：clean with errors或not clean whith errorsErrors behavior: ContinueFilesystem OS type: Linux #⽂件系统类型Inode count: 655360 #inode总的个数Block count: 2621440 #block总的个数Reserved block count: 131072Free blocks: 2554687 #空闲的block个数Free inodes: 655344 #空闲的iNode个数First block: 0 #第⼀个超级块编号=0Block size: 4096 #块⼤⼩，这⾥是4kFragment size: 4096 #分块⼤⼩Group descriptor size: 64Reserved GDT blocks: 1024 #保留的GDT块⼤⼩Blocks per group: 32768 #每个块组的block的个数Fragments per group: 32768Inodes per group: 8192 #每个块组的inode个数Inode blocks per group: 512…………三、查看备份块mkfs.ext4 -n /dev/sdb1（查看备份块时需要将分区卸载）linux-iu82:/ # mkfs.ext4 -n /dev/sdb1mke2fs 1.43.8 (1-Jan-2018)/dev/sdb1 contains a ext4 file systemlast mounted on /a on Wed Jun 1211:03:202019Proceed anyway? (y,N) yCreating filesystem with 2621440 4k blocks and 655360 inodes #块⼤⼩4kFilesystem UUID: 9e8e093e-183d-42ed-9e1f-b414673add53Superblock backups stored on blocks: #查看备份超级块32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632四、尝试修复超级块1. 1. 已知⽂件系统格式 1.1. 在已知⽂件系统的情况下可以直接使⽤： mkfs.type -n /dev/sdb1 进⾏查看分区的备份块。
linux操作系统故障处理-ext4文件系统超级块损坏修复
linux操作系统故障处理-ext4⽂件系统超级块损坏修复背景前天外⾯出差⼤数据测试环境平台有7台服务器挂了，同事重启好了五台服务器，但是还有两台服务器启动不起来，第⼆天回来后我和同事再次去机房检查，发现两台服务器都显⽰superblock的报错，经过⼀番处理后两台服务器都正常进系统了，现决定重现superblock故障并将此类问题故障处理思路写下来⽅便后⾯新同事参考。
硬盘的结构硬盘的物理结构侧视图和俯视图，这两张图传递出来的⽐较重要的信息如下：磁盘划分为磁头(Head),柱⾯(Cylinder)，扇区(Sector)磁头：每个磁⽚正反两⾯各有⼀个磁头，磁头固定在可移动的机械臂上，⽤于读写数据磁道：当硬盘盘⽚旋转时，磁头若保持在⼀个位置上，则磁头会在盘⽚表⾯划出⼀个圆形轨迹，这些圆形轨迹就叫做磁道，磁道由外向内从0开始编号。
柱⾯：磁⽚中半径相同的同⼼磁道(Track)构成柱⾯。
在实际应⽤中经常⽤到的磁盘分区就是⽤它作为范围划分的（重要）。
扇区：每个磁道上的⼀个弧段被成为⼀个扇区，它是硬盘的最⼩组成单元，⼀般扇区的⼤⼩是512字节。
了解了这⼏个概念就能算出⼀个分区的⼤⼩硬盘容量：磁头数*柱⾯数*扇区数*512磁盘sda的容量是： 255 * 2610 * 63 * 512 = 21467980800 ，算出的容量跟系统显⽰的基本⼀致。
[root@server1 ~]# fdisk -lDisk /dev/sda: 21.5 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x000205e3Device Boot Start End Blocks Id System/dev/sda1 * 12620480083 LinuxPartition 1 does not end on cylinder boundary./dev/sda2 26261120765696 8e Linux LVMDisk /dev/sdb: 10.7 GB, 10737418240 bytes255 heads, 63 sectors/track, 1305 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x00000000ext4⽂件系统由于Linux系统是多⽤户多的。
Linux命令行中的文件和权限修复技巧
Linux命令行中的文件和权限修复技巧在Linux系统中，文件和权限的管理是非常重要的一部分。
当我们遇到文件损坏或者权限错误的情况时，需要采取适当的修复措施。
本文将介绍一些在Linux命令行中常用的文件和权限修复技巧。
一、查找并修复损坏的文件当我们无法打开或操作一个文件时，很可能是文件损坏了。
我们可以使用文件系统检查工具来找出并修复这些损坏的文件。
常用的文件系统检查工具包括fsck和smartctl。
1. 使用fsck命令检查和修复文件系统：sudo fsck -y /dev/sda1该命令将检查并修复/dev/sda1分区上的文件系统。
2. 使用smartctl命令检查硬盘的健康状态：sudo smartctl -a /dev/sda该命令将显示/dev/sda硬盘的详细信息，包括健康状态和损坏情况。
二、修复文件权限问题在Linux系统中，文件权限的正确设置是非常重要的。
当我们无法访问或操作一个文件时，可能是由于权限设置错误导致的。
下面是一些修复文件权限问题的常用命令。
1. 使用chmod命令修改文件权限：sudo chmod 755 file.txt该命令将文件file.txt的权限设置为755，即所有者具有读、写和执行权限，其他用户具有读和执行权限。
2. 使用chown命令修改文件所有者：sudo chown user file.txt该命令将文件file.txt的所有者设置为user。
3. 使用chgrp命令修改文件所属组：sudo chgrp group file.txt该命令将文件file.txt的所属组设置为group。
三、修复损坏的软链接软链接是指向另一个文件或目录的符号链接。
当软链接损坏了，我们无法使用它指向的文件或目录。
下面是修复损坏的软链接的方法。
1. 使用ln命令重新创建软链接：ln -sf /path/to/target /path/to/link该命令将重新创建一个指向目标文件或目录的软链接。
修复XFS文件系统方法
修复XFS文件系统方法1、查看NAS挂载点root@StorOS ~# mount/dev/hda1 on / type ext3 (rw,acl)proc on /proc type proc (rw)devpts on /dev/pts type devpts (rw,gid=5,mode=620)tmpfs on /dev/shm type tmpfs (rw)sysfs on /sys type sysfs (rw)/dev/hda2 on /var type ext3 (rw,acl)/dev/hda3 on /b_iscsi type ext3 (rw,acl)/dev/mapper/st-nd on /nas/nas1 type xfs (rw) 备：XFS/dev/mapper/st-backup on /mnt/backup type ext3 (rw)2、停止nas服务root@StorOS ~# service smb stopShutting down SMB services: [ OK ] Shutting down NMB services: [ OK ]3、卸载文件挂载点root@StorOS ~# umount /nas/nas1备注：/nas/nas1是NAS的挂载目录。
4、确认/nas/nas1目录已没有挂载root@StorOS ~#mount5、修复NAS，注意输出结果。
备注：/dev/mapper/st-nd是nas目录的设备名，按照第一步骤mount查看结果更改root@StorOS ~# xfs_repair /dev/mapper/st-ndPhase 1 - find and verify superblock...Phase 2 - using internal log- zero log...- scan filesystem freespace and inode maps...- found root inode chunkPhase 3 - for each AG...- scan and clear agi unlinked lists...- process known inodes and perform inode discovery...- agno = 0data fork in ino 36099 claims free block 1077701646data fork in regular inode 36116 claims used block 1077701647bad data fork in inode 36116cleared inode 36116- agno = 1- agno = 2- agno = 3data fork in regular inode 3221253640 claims used block 1145585285bad data fork in inode 3221253640cleared inode 3221253640- agno = 4- agno = 5- agno = 6- agno = 7- agno = 8- agno = 9- agno = 10- agno = 11- agno = 12- agno = 13- agno = 14- agno = 15- agno = 16- agno = 17- agno = 18- agno = 19- agno = 20- agno = 21- agno = 22- agno = 23- agno = 24- agno = 25- agno = 26- agno = 27- agno = 28- agno = 29- agno = 30- agno = 31- process newly discovered inodes...Phase 4 - check for duplicate blocks...- setting up duplicate extent list...- clear lost+found (if it exists) ...- check for inodes claiming duplicate blocks...- agno = 0entry "耿__护牙_1.Wav" at block 5 offset 1864 in directory inode 140 references free inode 36116clearing inode number in entry at offset 1864...data fork in ino 34363 claims dup extent, off - 0, start - 1145585285, cnt 33bad data fork in inode 34363cleared inode 34363data fork in ino 36099 claims dup extent, off - 0, start - 1077701646, cnt 15bad data fork in inode 36099cleared inode 36099- agno = 1- agno = 2- agno = 3entry "1234_1.Wav" at block 3 offset 3048 in directory inode 3221225607 references free inode 3221253640clearing inode number in entry at offset 3048...- agno = 4- agno = 5- agno = 6- agno = 7- agno = 8- agno = 9- agno = 10- agno = 11- agno = 12- agno = 13- agno = 14- agno = 15- agno = 16- agno = 17- agno = 18- agno = 19- agno = 20- agno = 21- agno = 22- agno = 23- agno = 24- agno = 25- agno = 26- agno = 27- agno = 28- agno = 29- agno = 30- agno = 31Phase 5 - rebuild AG headers and trees...- reset superblock...Phase 6 - check inode connectivity...- resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory- traversing filesystem starting at / ...rebuilding directory inode 140rebuilding directory inode 3221225607entry "249_AutoSave_2.nxproj" in directory inode 36083 points to free inode 36099, marking entry to be junked rebuilding directory inode 36083entry "NEWAUTO22009012115475718086.sng" in directory inode 33885 points to free inode 34363, marking entry to be junkedrebuilding directory inode 33885- traversal finished ...- traversing all unattached subtrees ...- traversals finished ...- moving disconnected inodes to lost+found ...Phase 7 - verify and correct link counts...resetting inode 1073753124 nlinks from 1 to 2resetting inode 1073753127 nlinks from 1 to 2done备注：根据文件系统的损坏程度决定修复时间的长短。
一次Linux下testdisk+gdisk恢复XFS文件系统及数据的经历
⼀次Linux下testdisk+gdisk恢复XFS⽂件系统及数据的经历⼀次Linux下testdisk+gdisk恢复XFS⽂件系统及数据的经历硬盘之前状况,⽤gdisk进⾏硬盘分区（SATA标准，3.6T容量），1.6T+2.0T两个分区，然后⽤mkfs.xfs格式化分区，最后结果就是，GPT分区表+两个XFS⽂件系统的硬盘(/dev/sdb,/dev/sdb1,/dev/sdb2)我已⽆法确定引起这次硬盘错误的原因，但我确实这么做过：原因⼀,从另⼀个硬盘的/home挂载点复制了⼤量数据到/dev/sdb1,然后我就将硬盘的数据线和电源线都拔掉了，这个动作在系统运⾏和关闭的两种情况下都做过，（SATA 硬盘是否安全的⽀持热插拔？）原因⼆,在这次准备复制数据的之前，我没有将硬盘固定，也没有平放在台⾯（有⼀点斜度），然后开机，（胡乱的猜想着斜坡加载技术）下⾯进⼊正题：1,硬盘错误引起分区⽆法读取，挂载，开始纳闷哪⾥出了问题2，运⾏gdisk -l /dev/sdb,显⽰如下有警告信息及注意事项,虽然这⾥的标记GPT:damaged说明GPT有问题，但最后还是显⽰出了有分区的信息存在，（GPT分区表信息应该没有彻底损坏，不然怎么读取到两个分区的信息的呢），两个分区⾥Code标记都变成了0700（Microsoft basic data),正常的应该是8300（Linux filesystem），这个标记应该说明的是XFS⽂件系统的superblock信息毁了,这是后来经过XFS ⽂件系统⼯具xfs_repair知道的详细分区情况，但是是得出来的结果有问题的gdisk检测到五个问题，（惊讶，这么多的问题）3,进⾏到这⾥，我着急了，于是寻求帮助⾸先，尝试了xfs_repair /dev/sdb,这个命令进⾏了⼏次，因为中途中断过，这个修复时间是⽐较长的，⼏⼩时（差不多3，4⼩时？）后得到的结果却是⽆法检测验证到有效的备份superblock信息，（失败，⼼都凉了）然后，找到testdisk⼯具，⼤略的看了下说明就上⼿做（英⽂实在是差，仔细地看也不明⽩），第⼀次进⾏Analyse后，完全不知道做什么，就直接退出然后就去测试查看，运⾏lsblk，gdisk，没有任何改变，（此刻是没抱什么希望的），输出的⽇志⽂件testdisk.log也完全看不懂，但我在⽇志⽂件⾥看到了有XFS这三个字母的⾝影，（此时⼼中还是有⼀丝喜悦的）4,继续⽹上搜索，寻求答案，（⾟⾟苦苦建⽴的⽂件数据啊，那个⼼情真是⽆奈啊）使⽤testdisk进⾏第⼆次Analyse(分析⽬前分区结构及搜寻丢失的分区），经过6⼩时的分析与搜索后，我⼤胆的进⾏了第⼆个动作，转换分区类型，（当时的想法是inode及data block⾥记录的信息应该是不会丢失或被覆盖的），于是我选择了Linux reserved（⾕歌翻译了⼀下，“Linux保留”，这⾥是没有Linux filesystem 的，找来找去也没找到更合适的了），再进⼊⼦菜单选择了XFS（还有XFS2,XFS3，XFS4，这⾥是⽐较疑惑的，⽹上没有找到任何答案），⾄此点击写⼊，然后退出。
Linux系统硬盘出现故障的修复方法
Linux系统硬盘出现故障的修复方法导读:Linux系统硬盘在使用过程中会出现一些坏道，如果坏道发生在系统关键区域，就会损坏系统文件，出现各种错误。
本文就来介绍一下，本文就来教大家Linux系统硬盘出现故障的修复方法。
故障提示：Jul 17 00:46:34 xxxxxxxxxxxxxx kernel：［8384801.159283］EXT4-fs （sdl1）：warning：mounting fs with errors，running e2fsck is recommended Jul 17 00:50:00 xxxxxxxxxxxxxx kernel：［8385006.016500］sd 6:0：6:0：［sdl］Sense Key ：Medium Error ［current］Jul 17 00:50:00 xxxxxxxxxxxxxx kernel：［8385006.016508］sd 6:0：6:0：［sdl］Add. Sense：Unrecovered read errorJul 17 00:50:00 xxxxxxxxxxxxxx kernel：［8385006.016524］Buffer I/O error on device sdl1，logical block 1415594116Jul 17 00:50:00 xxxxxxxxxxxxxx kernel：［8385006.095561］Buffer I/O error on device sdl1，logical block 1415594117故障解决：#e2fsck /dev/sdl11、若坏的block无法修复，则需要用fdisk格式化硬盘：#fdisk /dev/sdl#d#n#p#Enter#Enter#w2、用ext4文件系统格式化磁盘：#mkfs.ext4 /dev/sdl13、把格式化好的硬盘mount回来：#mount -L /Hadoop07 /hadoop/7 -t ext4 -o defaults，noatime，nodiratime，noauto若几天后发现/var/log/messages里面有最新的/dev/sdl的错误日志，则表明此硬盘需要更换了，这时可以先禁掉这块盘所挂在目录的读写功能，在此之前你可以先把里面的数据拷贝出来：#chmod 0 /hadoop07以上就是Linux系统硬盘出现故障的修复方法了，当然如果是物理的坏道，那就是硬盘本身的问题，那是不能用这种方法修复的。
Linux上的文件恢复和数据修复技巧
Linux上的文件恢复和数据修复技巧在Linux系统中，文件恢复和数据修复是一项重要的技能。
无论是因为误删除、文件系统损坏，还是因为磁盘故障，我们都可能面临文件丢失的情况。
此时，了解一些Linux上的文件恢复和数据修复技巧将非常有帮助。
本文将介绍几种常用的方法，帮助您在Linux系统中有效地恢复丢失的文件和修复损坏的数据。
1. 使用已删除文件恢复工具即使文件在Linux系统中被删除了，它们的实际数据仍然存在于磁盘上，只是文件系统已不再将其视为有效文件。
因此，通过使用一些专门的工具，我们可以恢复这些已删除的文件。
在Linux中，一些常用的文件恢复工具包括extundelete、TestDisk和PhotoRec等。
这些工具可以扫描磁盘，找到已删除的文件并将其恢复。
2. 使用文件系统修复工具当文件系统损坏时，我们无法正常地访问文件或者出现一些奇怪的问题。
此时，我们可以使用一些文件系统修复工具来修复这些问题。
例如，在ext4文件系统中，可以使用e2fsck工具来检测和修复文件系统中的错误。
通过运行e2fsck命令，系统将扫描文件系统并尝试修复错误，恢复文件系统的可用性。
3. 使用数据恢复工具当磁盘故障导致数据无法访问时，我们可以使用一些数据恢复工具来尝试恢复丢失的数据。
例如，当磁盘损坏时，可以使用ddrescue工具从故障的磁盘中复制数据到另一个磁盘。
然后，我们可以使用工具如TestDisk和PhotoRec来恢复从故障磁盘中复制的数据。
4. 创建数据备份在Linux系统中，定期创建数据备份是非常重要的。
如果您的文件丢失或者数据损坏，备份可以帮助您快速恢复文件和数据。
可以使用一些工具如rsync或者tar来创建数据备份。
您可以将备份保存在外部设备或者云存储中，以确保数据的安全性和可用性。
5. 使用RAID技术RAID技术（磁盘阵列）可以提供磁盘冗余和容错功能，以保护数据免受磁盘故障的影响。
在Linux系统中，可以通过软件RAID或者硬件RAID来实现数据的冗余。
修复损坏的系统文件的几种方法
修复损坏的系统文件的几种方法
修复损坏的系统文件有多种方法，以下是一些常见的方法：
1. 使用系统文件检查器（SFC）：在命令提示符下输入“sfc /scannow”，该命令将扫描所有受保护的系统文件，并修复损坏的文件。
2. 自动系统修复：在Windows系统中，有一个自动系统修复工具，可以修复一些常见的系统文件损坏问题。
可以通过“开始”菜单中的“自动系统恢复”来启动该工具。
3. 使用系统还原：如果系统文件损坏不太严重，可以使用系统还原功能将系统还原到之前的某个时间点，从而恢复损坏的文件。
4. 从安装光盘或U盘恢复：如果系统文件损坏严重，无法通过上述方法修复，可以考虑从安装光盘或U盘恢复。
可以使用Windows安装光盘或U
盘启动系统，并选择修复计算机选项来恢复系统文件。
5. 手动修复：如果具有一定的技术知识，可以手动定位损坏的系统文件并将其替换为正常的文件。
但这种方法需要谨慎操作，以免造成更大的问题。
需要注意的是，对于一些严重的系统文件损坏问题，可能需要重新安装Windows系统来解决。
在修复系统文件之前，建议备份重要的数据和文件，以免在修复过程中造成数据丢失。
[转载]在Linux中使用fsck命令修复文件系统
![[转载]在Linux中使用fsck命令修复文件系统](https://img.taocdn.com/s3/m/e91640771fd9ad51f01dc281e53a580216fc5060.png)
[转载]在Linux中使⽤fsck命令修复⽂件系统背景：fsck(⽂件系统检查)是⼀种命令⾏实⽤程序，可让您在⼀个或多个 Linux ⽂件系统上执⾏⼀致性检查和交互式修复。
它的程序独⽴于所检查⽂件的系统类型。
在系统⽆法启动或⽆法挂载分区的情况下，可以使⽤ fsck 命令修复损坏的⽂件系统。
在本⽂中，我们将讨论 fsck 命令。
重点：1、我们不应该⽤ fsck 检查已挂载的磁盘，这很可能会对磁盘造成永久性的伤害。
因此在开始使⽤ fsck 之前，我们需要使⽤下⾯命令来卸载磁盘如何使⽤ fsckfsck 命令采⽤以下⼀般形式：fsck [OPTIONS] [FILESYSTEM]操作指南：基本操作：$ umount/dev/sdb1$ fsck/dev/sdb1检查⽂件系统错误并⾃动修复使⽤选项 -a 进⾏⼀致性检查并⾃动修复这些错误。
也可以⽤ -y 替代 -a 选项。
$ fsck -a /dev/sdb1检查⽂件系统错误但并不进⾏修复若我们只想知道⽂件系统上有哪些错误⽽不想修复这些错误，那么可以使⽤选项 -n，$ fsck-n /dev/sdb1只检查指定⽂件系统类型的分区使⽤选项 -t 及⽂件系统类型，可以让 fsck 只检查指定⽂件系统类型的分区，⽐如指定⽂件系统类型为 “ext4”，$ fsck-t ext4 /dev/sdb1或者，$ fsck-t -A ext4只有 root 或具有 sudo 特权的⽤户才能清除缓冲区。
当 FILESYSTEM 参数不提供时， fsck 检查 fstab ⽂件中列出的设备。
切勿在已挂载的分区上运⾏ fsck ，因为这可能会损坏⽂件系统。
在尝试检查或修复⽂件系统之前，请先进⾏操作 unmount 。
fsck 命令是各种 Linux ⽂件系统检查器 (fsck.*) 的包装，并且根据⽂件系统的类型接受不同的选项。
可以在⼿册页以获取有关特定检查器的更多信息。
例如，要查看 fsck.ext4 可⽤的选项，请输⼊：man fsck.ext4修复损坏的⽂件系统该 fsck 命令最简单的⽤例是修复⽆根损坏的 ext3 或 ext4 ⽂件系统。
LinuxFSCK自动修复文件系统
LinuxFSCK自动修复文件系统背景：Linux系统（Ubuntu）在运行时，断电等非正常关机操作，会导致ext4文件系统数据损坏。
严重时会导致系统崩溃。
如下log就是系统数据损坏。
检查方法：1、开机log，如上log就是开机时，kernel监测到文件系统错误:[ 7.878756] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:742: group 0, 14845 clusters in bitmap, 14822 in gd [ 8.484660] init: samba-ad-dc main process (995) terminated with status 1[ 14.248075] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:742: group 1, 1 clusters in bitmap, 2 in gd2、比如要检查的分区是/dev/mmcblk0p2，如下红色字体部分就是系统错误的信息。
~# tune2fs -l /dev/mmcblk0p2tune2fs 1.42.9 (4-Feb-2014)Filesystem volume name: <none>Last mounted on: /Filesystem UUID: ab013911-6048-465f-8a1a-cf1420c7bb01Filesystem magic number: 0xEF53Filesystem revision #: 1 (dynamic)Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isizeFilesystem flags: unsigned_directory_hashDefault mount options: user_xattr aclFilesystem state: not clean with errors Errors behavior: ContinueFilesystem OS type: LinuxInode count: 393216Block count: 1572864Reserved block count: 78643Free blocks: 289870Free inodes: 169990First block: 0Block size: 4096Fragment size: 4096Reserved GDT blocks: 383Blocks per group: 32768Fragments per group: 32768Inodes per group: 8192Inode blocks per group: 512Flex block group size: 16Filesystem created: Sat Sep 12 11:55:02 2015 Last mount time: Mon Oct 5 00:56:20 2015 Last write time: Mon Oct 5 00:56:32 2015 Mount count: 49Maximum mount count: -1Last checked: Sat Sep 12 11:55:02 2015 Check interval: 0 (<none>)Lifetime writes: 5936 MBReserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root)First inode: 11Inode size: 256Required extra isize: 28Desired extra isize: 28Default directory hash: half_md4Directory Hash Seed: 37b6421d-4697-4ff5-a68e-4a1e1ea81c0eJournal backup: inode blocksFS Error count: 5First error time: Mon Oct 5 00:52:47 2015First error function: ext4_mb_generate_buddyFirst error line #: 742First error inode #: 0First error block #: 0Last error time: Mon Oct 5 00:56:32 2015Last error function: ext4_mb_generate_buddyLast error line #: 742Last error inode #: 0Last error block #: 0修复方法：1、手动修复：借助其他完整系统启动，对所在磁盘分区卸载，比如要修复/dev/mmcblk0p2,执行命令 fsck.ext4 /dev/mmcblk0p2 可检查修复系统；2、自动修复：条件：（1）、自动修复要保证，bootloader参数bootargs 生命挂载以制度方式挂载根文件系统console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro如果最后ro是rw，将不能完成自动修复。
fsck后数据丢失的数据恢复方案
基于linux系统，fsck后数据丢失的数据恢复方案一、总述：基于linux系统，fsck后数据丢失的数据恢复方案二、解决方案2.1 恢复流程2.1.1 检测流程1、检测是否存在硬件故障，如硬件故障，转硬件处理2、以只读方式检测故障表现是否与用户描述相同2.1.2 恢复流程1、备份：以只读方式对故障磁盘做完整镜像(参考附录)2、如果需要恢复完整目录结构，则先需要完整恢复已丢失文件节点，再恢复数据。
如果节点无法恢复，则可按文件类型进行恢复。
3、恢复后的数据会暂存在另一个存储体上2.1.3 验收流程对恢复好的数据进行验证，确认其正确性。
如确认，交费-->移交原介质及已恢复数据 -->出具发票(收据)及报告。
如无法确认或不确认，移交原介质不收服务费，可免费出具报告。
三、数据恢复的可能性fsck会校验文件系统节点、数据索引之间的匹配关系，修复时会试图重新生成文件系统目录树，并一致化节点与索引的关系，当文件系统结构不一致时，就会占用新的空间生成一致性的元数据结构，有时候，这种操作会破坏恢复现场，导致数据恢复工作更加困难甚至无法完成。
fsck时如果有大量节点报错并提示已经修复，这种破坏是非常严重的，数据恢复将很困难。
目录结构及文件名称是最容易被破坏的，这会导致所恢复出来的数据彻底丢失原有的目录结构和文件名称。
fsck执行后，如果很短时间就完成，则无论执行修复后的结果如何，数据恢复的可能性均较高。
四、数据恢复所需时间影响数据恢复的时间有多方面的因素。
通常，数据恢复服务约需要2-3天，如遇复杂情况，需要视情况而定。
六、小贴士1、存储设备没有100%的安全保证，重要数据需要常常备份，可以采用一些数据同步工具进行数据备份。
2、出现数据灾难时，本机不应再有任何操作，如有条件，应该将硬盘或其他存储介质完整镜像（参考附录）3、数据删除后，即使不写数据，单纯的读取也容易破坏文件系统日志，所以，出故障后，应尽快umount文件系统。
如何修复损坏的系统文件
如何修复损坏的系统文件系统文件是操作系统正常运行所必需的重要文件，一旦这些文件损坏或丢失，就会导致系统出现各种问题，影响电脑的正常使用。
本文将介绍几种常见的修复损坏系统文件的方法，帮助读者解决这一问题。
一、使用系统自带的修复工具大多数操作系统都提供了自带的修复工具，可以帮助用户修复损坏的系统文件。
以下是两种常见的修复工具：1. Windows系统的SFC命令SFC（系统文件检查器）是Windows系统自带的命令工具，可以扫描并修复操作系统中的损坏文件。
使用SFC命令修复系统文件的步骤如下：1）按下Win + R组合键，打开运行对话框；2）输入“cmd”并按下回车键，打开命令提示符窗口；3）在命令提示符窗口中输入“sfc /scannow”并按下回车键，系统会开始扫描并修复损坏的文件。
2. macOS系统的Disk Utility工具MacOS系统提供了Disk Utility（磁盘工具）来修复文件系统的损坏。
使用Disk Utility工具修复文件系统的步骤如下：1）打开Finder，选择“应用程序”-“实用工具”-“Disk Utility”；2）在Disk Utility界面中，选择需要修复的磁盘，点击“修复”按钮；3）等待修复过程完成后，重新启动电脑。
二、使用第三方修复软件除了系统自带的修复工具，还有一些第三方的修复软件可以帮助修复损坏的系统文件。
以下是两种常见的修复软件：1. SFCFix（适用于Windows系统）SFCFix是一款免费的修复工具，专门用于修复Windows系统中的损坏文件。
使用SFCFix修复系统文件的步骤如下：1）在浏览器中搜索并下载SFCFix软件；2）运行SFCFix软件，并按照提示进行操作，等待修复过程完成。
2. Onyx（适用于macOS系统）Onyx是一款免费的优化和维护工具，它包含了修复文件系统的功能。
使用Onyx修复文件系统的步骤如下：1）在浏览器中搜索并下载Onyx软件，选择适合自己系统版本的版本进行下载；2）安装并打开Onyx软件，在“维护”选项中找到“遍历”选项卡；3）勾选“修复权限”和“检查S.M.A.R.T.”选项，并点击“执行”按钮进行修复。
fsck.ext4交叉编译
fsck.ext4交叉编译
在Linux系统中，fsck.ext4是用于检查和修复ext4文件系统
的工具。
交叉编译是指在一种平台上生成另一种平台的可执行代码。
在进行fsck.ext4的交叉编译时，我们需要考虑以下几个方面：
1. 目标平台的架构，确定要在哪种架构的平台上运行交叉编译
后的fsck.ext4。
例如，如果我们希望在ARM架构的嵌入式设备上
运行fsck.ext4，则需要选择ARM架构作为目标平台。
2. 工具链的准备，为目标平台选择合适的交叉编译工具链，这
包括交叉编译器、交叉链接器等工具。
通常可以从Linux发行版的
软件仓库或者第三方工具链提供商处获取适合目标平台的工具链。
3. 构建过程，在进行交叉编译之前，需要对fsck.ext4的源代
码进行配置和构建。
这可能涉及到一些特定于目标平台的配置选项，例如指定目标架构、交叉编译器的路径等。
4. 测试和调试，在完成交叉编译后，需要在目标平台上进行测
试和调试。
确保交叉编译后的fsck.ext4能够正确地检查和修复
ext4文件系统，并且在目标平台上稳定运行。
总的来说，进行fsck.ext4的交叉编译需要考虑到目标平台的架构、工具链的准备、构建过程以及测试和调试等方面。
这样才能确保交叉编译后的fsck.ext4能够在目标平台上正常运行。
Linux出现Read-onlyfilesystem错误的解决方法
Linux出现Read-onlyfilesystem错误的解决⽅法⾸先，重启看看能否解决，如果不⾏再尝试下⾯两种⽅法：造成这个问题的原因⼤多数是因为⾮正常关机后导致⽂件系统受损引起的，在系统重启之后，受损分区就会被Linux⾃动挂载为只读。
解决的⽅法是通过fsck来修复⽂件系统，然后重启即可，以下是以针对/dev/xvde1分区，ext4⽂件系统分区的⼀个操作案例：fsck.ext4 -y /dev/xvde1本⽂只着重强调⼀点：要针对出问题的分区进⾏操作，在挂载了多个硬盘的机器上要仔细分辨⼀下。
报错read-only file system的原因是你所在的分区只有读权限，没有写权限mount为挂载分区命令，mount -o remount -w 重新挂载分区并增加写权限，增加读写权限即为 -rw问题：push 某个⽂件到⽬标板（⽐如/data⽬录下）时，提⽰其⽬录是只读的；可通过如下命令，将⽬标⽬录临时变更为可读写模式：解决⽅法：mount -o remount -rw /data【扩展：】重新挂载为已经挂载了的⽂件系统（以读写权限挂载），需要注意的是，挂载点必须是⼀个已经存在的⽬录，这个⽬录可以不为空。
⼀般⽤于此⽬录下的⽂件为ro权限，需要临时变更为可修改权限。
参数：-o <选项> 指定挂载⽂件系统时的选项，有些也可写到在 /etc/fstab 中。
常⽤的有：defaults 使⽤所有选项的默认值（auto、nouser、rw、suid）auto/noauto 允许/不允许以 –a选项进⾏安装dev/nodev 对/不对⽂件系统上的特殊设备进⾏解释exec/noexec 允许/不允许执⾏⼆进制代码suid/nosuid 确认/不确认suid和sgid位user/nouser 允许/不允许⼀般⽤户挂载codepage=XXX 代码页iocharset=XXX 字符集ro 以只读⽅式挂载rw 以读写⽅式挂载remount 重新安装已经安装了的⽂件系统loop 挂载“回旋设备”以及“ISO镜像⽂件”1、mount:⽤于查看哪个模块输⼊只读，⼀般显⽰为：[root@localhost ~]# mount/dev/cciss/c0d0p2 on / type ext3 (rw)proc on /proc type proc (rw)sysfs on /sys type sysfs (rw)devpts on /dev/pts type devpts (rw,gid=5,mode=620)/dev/cciss/c0d0p7 on /home type ext3 (rw)/dev/cciss/c0d0p6 on /var type ext3 (rw)/dev/cciss/c0d0p3 on /usr type ext3 (rw)/dev/cciss/c0d0p1 on /boot type ext3 (rw)tmpfs on /dev/shm type tmpfs (rw)none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)/dev/dm-0 on /home/book/upload/BookFile1 type ext3 (rw)/dev/dm-1 on /home/book/upload/BookFile2 type ext3 (rw)/dev/dm-2 on /backup type ext3 (rw)/dev/dm-3 on /home/book/upload/BookFile3 type ext3 (ro)2、如果发现有ro，就重新mount，或者umount以后再remount3、umount /dev/dm-3如果发现有提⽰“device is busy”，找到是什么进程使得他busyfuser -m /mnt/data 将会显⽰使⽤这个模块的pidfuser -mk /mnt/data 将会直接kill那个pid然后重新mount即可。
Linux使用fsck修复文件系统
Linux使⽤fsck修复⽂件系统1、fsck---file system checkfsck 扫描⽂件系统时⼀定要在单⽤户模式、修复模式或把设备umount后进⾏。
如果扫描运⾏中的系统，会造成系统⽂件损坏。
RHEL6中fsck默认⽀持⽂件系统ext4，如果想⽀持ext3⽂件系统的扫描，应该加-j 参数。
最好是根据不同的⽂件系统来调⽤不同的扫描⼯具，⽐如ext3的⽂件系统使⽤fsck.ext3，ext2⽂件系统使⽤fsck -t etx2等。
参数：-a : 如果检查有错则⾃动修复-r : 如果检查有错则由使⽤者回答是否修复-t : <⽂件系统类型> 指定要检查的⽂件系统类型。
-s : 依序⼀个⼀个地执⾏ fsck 的指令来检查-A : 对/etc/fstab 中所有列出来的 partition 做检查-C : 显⽰完整的检查进度-d : 列印 e2fsck的 debug 结果-p : 同时有 -A 条件时，同时有多个 fsck 的检查⼀起执⾏-R : 同时有 -A 条件时，省略 / 不检查-V : 详细显⽰模式执⾏后的传回值及代表意义：0 没有任何错误发⽣。
1 ⽂件系统发⽣错误，并且已经修正。
2 ⽂件系统发⽣错误，并且已经修正。
4 ⽂件系统发⽣错误，但没有修正。
8 运作时发⽣错误。
16 使⽤的语法发⽣错误。
128 共享的函数库发⽣错误。
2、检查 ext4 ⽂件系统的 /dev/sdb3 是否正常，如果有异常便⾃动修复[root@test ~]# fsck -t ext4 -a /dev/sdb33、出现如下提⽰可以使⽤fsck命令来修复1）⽆法mount分区;2）⼤量⽂件、⽬录丢失，根⽬录下⽣成/LOST+FOUND⽂件夹，⾥⾯有⼤量#XXXXXX类的⽂件和⽬录;3）fsck很快报错完成;4）fsck执⾏时，有⼤量提⽰，如修改节点、清0节点等操作4、当Linux系统被强⾏关闭或重新启动，⽂件系统可能受到损坏，系统启动时会⾃动检查并修复⽂件系统但是当⽂件系统没有⾃动修复成功时，便需要⼿动使⽤fsck进⾏扫描和修复。
Linux下文件系统superblock故障修复
Linux下文件系统superblock故障修复故障修复superblockLinux下文件系统记一次superblock 损坏导致服务器无法启动的故障修复的服务器，前几天接到朋友联系，说他的服务器坏了，启动不起来了。
这是一个RHEL 4我也很久4，也就是说没有售后服务的，联系我问问能不能帮帮忙。
而且是那种盗版RHEL系统上的东西了。
只好尝试一下，庆幸的是，修好了，并帮朋友维护了一没有弄过Linux本身并不复杂，我觉段时间，在此记录一些修复和维护中碰到的问题。
修复superblock得值得记录的是修复过程中的思考过程，和修复所需要注意的问题。
一、启动故障系统无法启动，启动时内核panic：Uncompressing Linux Ok, booting the kernel.audit(1297269214.612:0): initializedide2: I/O resource 0x3F6-0x3F6 not free.ide2: ports already in use, skipping probeRed Hat nash version 4.1.18 startingFile descriptor 3 left openReading all physical volumes. This may take a while/dev/hda: open failed: No medium foundFound volume group VolGroup_ID_17253 using metadata type lvm2File descriptor 3 left open8 logical volume(s) in volume group VolGroup_ID_17253 now activeFile descriptor 3 left openVFS: Can't find ext3 filesystem on dev dm-0.mount: error 22 mounting ext3mount: error 2 mounting noneswitchroot: mount failed: 22umount /initrd/dev failed: 2Kernel panic - not syncing: Attempted to kill init!_看到这个报错，我Google了一下，很快就发现，这很有可能是硬盘的superblock [1]坏了，因此感觉需要修复superblock。