一次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，这里是比较疑惑的，网上没有找到任何答案），至此点击写入，然后退出。
再一次阅读testdisk.log文件，（这里有点小插曲，我在主文件侠里找不到testdisk.log文件，进行whereis testdisk.log搜寻，这个文件怎么会跑
到/usr/src/linux-3.10.3-1-ARCH/testdisk.log这里了呢）？
5,testdisk.log文件内容如下：
这里是系统的一些相关信息
这里是选择了EFI GPT选项后得出的结果，在这里就分析出了当前的分区结构，只有一个Linux Reserved分区类型的分区，（这里的这个分析是不是肯定的）
这里是应该是选择了Analyse选项后再点击quick search得到的，大概是两段内容，第一，对于分区1文件系统的标记搜索，成功，（这个标记是什么，superblock？，不是损毁了吗？）。
第二，对于分区2文件系统的标记搜索，在这里搜索到了很多标记，但是在比对数据（能这样表达吗）时却出现了问题，（这里应该就是为什么会耗时6小时的原因)，因为数据的信息标记超出了磁盘的整个容量，（这会是什么原因造成的呢）
这里是搜索完成后得到无法恢复分区2文件系统的信息
这里是这次使用testdisk最后的结果日志，只找到了丢失的分区1文件系统，然后进行了分区类型的改变和确定写入。
6,经过上步的尝试，（说实话，心里很忐忑），使用lsblk查找，还是找不
到/dev/sdb1,于是运行gdisk
虽然看到不想看到的信息，但是No problems found一句让我有些惊喜，继续
作出决定，重写分区表信息7,喜出望外的结果
检测出/dev/sdb/sdb1
成功挽回文件！（兴奋啊）8,疑问与猜想
GPT分区表已经修复好，分区1的类型为Linux reserved（并不是未出问题之前的Linux filesystem），成功检测到/dev/sdb1的文件系统是XFS。
已经挽回了数据，虽然并没有完整的修复，但现在没有空闲的磁盘来备份这些数据，所以这里就没敢继续往下尝试恢复了
疑问一：能不能直接使用gdisk的重新建立分区表的功能，使用testdisk好像最主要的作用就是做了分区的搜索，然后做了个分区类型的转换（这步是否可用其它工具完成）？
疑问二：XFS文件系统的superblock到底有没有损毁，如果没有损毁，怎么就检测不到分区文件系统信息，如果损毁了又是怎么恢复的，因为尝试运行了xfs_repair,检测到磁盘最后一个扇区也验证不了备份的superblock。
superblock有没有彻底恢复，如果是彻底恢复的，为什么不能正确的检测到分区2的信息，如果并不是完整的superblock，又何以能够读取分区1的作息？
疑问三：总觉得这里的Linux reserved怪怪的，难道它在磁盘里的记录信息与Linux filesystem是兼容的？这个记录信息与XFS文件系统的superblock有没有关系？
疑问四：运行dd if=/dev/sdb of=/dev/sdax,会是什么结果？
猜想疑问一：阅读了鸟哥的私房菜基础篇里的ext2文件系统的那一章节，对文件系统（ext2,ext3,ext4，XFS）有这么个了解，记录整个磁盘分区情况的是GPT分区表，记录分区文件系统信息的是superblock，记录文件系统里的文件信息的是inode，记录文件系统里的文件实际数据的是block，这里的inode与block是否有独特的标记，是否可写这样一个程序，直接读取到磁盘里的inode来找到block
从而搜索出文件信息
猜想疑问二：说到这里当然还有一些疑问，这里的思维有些乱。
GPT磁盘在开始区域
记录着保留的MBR信息，GPT信息及superblock信息，这些是怎么记录下来的，因为这个区域没有进行文件系统格式化，磁盘的整个磁盘的最小单位是sector（扇区），进行分区文件系统格式化后，磁盘用来记录信息的最小单位是block吗，那么
默认256bytes的inode又是个什么，superblock信息为什么会记录在第一个
分区以前未格式化的区域？
此篇小记说明：以上信息仅针对本人使用的系统环境，其中有一小部份表达的信息无法
用图片来比对，因为一开始没想要写此记，所以一些信息的截图就忽略了，特别是
xfs_repair这个环节。
最后作个提醒：硬盘发生错误，在系统运行期间无法自动fsck导致系统无法成功启动
或无法检测分区读取数据信息（非启动盘）后，绝不能再对硬盘进行任何写操作，慎用fsck，切记，切记，这样，自己就能最有把握的将数据拯救出来！。