fsck

（一）备份namenode的元数据 namenode中的元数据非常重要，如丢失或者损坏，则整个系统无法使用。因此应该经常对元数据进行备份，最好是异地备份。 1、将元数据复制到远程站点 （1）以下代码将secondary namenode中的元数据复制到一个时间命名的目录下，然后通过scp命令远程发送到其它机器 #!/bin/bash export dirname=/mnt/tmphadoop/dfs/namesecondary/current/`date +%y%m%d%H` if [ ! -d ${dirname} ] then mkdir ${dirname} cp /mnt/tmphadoop/dfs/namesecondary/current/* ${dirname} fi scp -r ${dirname} slave1:/mnt/namenode_backup/ rm -r ${dirname} （2）配置crontab，定时执行此项工作 0 0,8,14,20 * * * bash /mnt/scripts/namenode_backup_script.sh 2、在远程站点中启动一个本地namenode守护进程，尝试加载这些备份文件，以确定是否已经进行了正确备份。 （二）数据备份 对于重要的数据，不能完全依赖HDFS，而是需要进行备份，注意以下几点 （1）尽量异地备份

环境为linux，某分区数据无法读取。 1.fstab及磁盘列表正常。 2.手动挂在时系统提示can't read superblock on /dev/xxx 故障现象如上图。 解决办法。root下使用fsck，进行修复指定分区。 fsck /dev/xxx (fsck /dev/xxx -y） 运行结果如下图： 完成后，重新挂在即可。 来源： 51CTO 作者： ghostrt 链接： https://blog.51cto.com/3142515/2116620

看到这个链接：https://askubuntu.com/questions/955467/dev-sda1-contains-a-file-system-with-errors-check-forced/955504 有一个高赞答案： At the (initramfs) prompt, type fsck -f /dev/sda1 to check/repair your file system. 翻译：在（initramfs）提示符下，键入 fsck -f / dev / sda1 以检查/修复文件系统。 中间提示是否yes输入y即可，看到结束提示 FILE SYSTEM WAS MODIFIED 重启系统后OK 使用的这个方式，重启电脑后成功了。 具体原因不详，有人说是“/dev/sda2这块硬盘的逻辑卷无法加载所致”。 另外一个链接：https://blog.csdn.net/BabyFish13/article/details/51190148 1、解决参考一 Press enter for maintenance (or type Control-D to continue): /dev/sda3 contains a file system with errors, check forced. /dev/sda3: Inodes that were part of

修复一下 fsck -y /dev/sdb1 重启 reboot 参考 ：先找到你的kali或者其他Linux系统安装的磁盘分区，在initramfs下输入blkid命令可以查看所有磁盘，然后找到TYPE=“ext4”的分区;记录下磁盘的名字，我的是/dev/sda7； 2：通过U盘进入kali live模式的方法对本地磁盘进行操作；首先卸载你的分区：umount /dev/sda7 3：用fsck命令开始检查、修复（fsck是个很好用了磁盘检测修复命令）输入：fsck -t ext4 /dev/sda1 (-t是指定文件系统类型：现在的多半是ext3和ext4，不知道，你就一个一个试！）最后回车后它会问你是否继续，你就一路按y就行了！到最后会它完了之后：shutdown -r now（重启命令）关机开机就基本好了！ 来源： CSDN 作者： ceramic_yu 链接： https://blog.csdn.net/ceramic_yu/article/details/103457913

我经常使用 git stash 和 git stash pop 来保存和恢复工作树中的更改。 昨天，我在工作树中进行了一些隐藏和弹出的更改，然后对工作树进行了更多更改。 我想回顾一下昨天的隐藏更改，但是 git stash pop 似乎删除了对关联提交的所有引用。 我知道，如果我使用 git stash 则 .git / refs / stash包含 用于创建隐藏的提交的引用。 .git / logs / refs / stash包含 整个存储。 但是这些引用在 git stash pop 之后消失了。 我知道提交仍在我的存储库中的某个位置，但是我不知道它是什么。 有没有简单的方法来恢复昨天的隐藏提交参考？ 请注意，这对我今天并不重要，因为我每天都有备份，可以回到昨天的工作树中进行更改。 我问，因为必须有一个更简单的方法！ #1楼 当您没有gitk可用或没有X输出时，我想向接受的解决方案中添加另一种进行所有更改的好方法。 git fsck --no-reflog | awk '/dangling commit/ {print $3}' > tmp_commits for h in `cat tmp_commits`; do git show $h | less; done 然后，您将获得这些散列的所有差异。 按“ q”进入下一个差异。 #2楼 我喜欢亚里斯多德的方法

我经常使用 git stash 和 git stash pop 来保存和恢复工作树中的更改。 昨天，我在工作树中进行了一些隐藏和弹出的更改，然后对工作树进行了更多更改。 我想回顾一下昨天的隐藏更改，但是 git stash pop 似乎删除了对关联提交的所有引用。 我知道，如果我使用 git stash 则 .git / refs / stash包含 用于创建隐藏的提交的引用。 .git / logs / refs / stash包含 整个存储。 但是这些引用在 git stash pop 之后消失了。 我知道提交仍在我的存储库中的某个位置，但是我不知道它是什么。 有没有简单的方法来恢复昨天的隐藏提交参考？ 请注意，这对我今天并不重要，因为我每天都有备份，可以回到昨天的工作树中进行更改。 我问，因为必须有一个更简单的方法！ #1楼 当您没有gitk可用或没有X输出时，我想向接受的解决方案中添加另一种进行所有更改的好方法。 git fsck --no-reflog | awk '/dangling commit/ {print $3}' > tmp_commits for h in `cat tmp_commits`; do git show $h | less; done 然后，您将获得这些散列的所有差异。 按“ q”进入下一个差异。 #2楼 我喜欢亚里斯多德的方法

我经常使用 git stash 和 git stash pop 来保存和恢复工作树中的更改。 昨天，我在工作树中进行了一些隐藏和弹出的更改，然后对工作树进行了更多更改。 我想回顾一下昨天的隐藏更改，但是 git stash pop 似乎删除了对关联提交的所有引用。 我知道，如果我使用 git stash 则 .git / refs / stash包含 用于创建隐藏的提交的引用。 .git / logs / refs / stash包含 整个存储。 但是这些引用在 git stash pop 之后消失了。 我知道提交仍在我的存储库中的某个位置，但是我不知道它是什么。 有没有简单的方法来恢复昨天的隐藏提交参考？ 请注意，这对我今天并不重要，因为我每天都有备份，可以回到昨天的工作树中进行更改。 我问，因为必须有一个更简单的方法！ #1楼 当您没有gitk可用或没有X输出时，我想向接受的解决方案中添加另一种进行所有更改的好方法。 git fsck --no-reflog | awk '/dangling commit/ {print $3}' > tmp_commits for h in `cat tmp_commits`; do git show $h | less; done 然后，您将获得这些散列的所有差异。 按“ q”进入下一个差异。 #2楼 我喜欢亚里斯多德的方法

怎么使用chkdsk命令修复磁盘 fsck|xfs_repair 磁盘修复 fsck 使用权限 : 超级使用者 　　 　　使用方式 : fsck [-sACVRP] [-t fstype] [--] [fsck-options] file sys [...] 　　 　　说明 ： 在Linux系统中，为了增加系统性能，通常系统默认一些数据写在内存中，并不会直接将数据写入硬盘，这是因为内存速度要比硬盘快若干倍。但是有个问题，万一由于“断电”或者其他未知原因，造成系统死机，怎么办？系统就崩溃了。所以，我们需要在特定的时候让数据直接回存到硬盘中。这里提供几个常用的命令，其中，fsck命令最重要. 当文件系统发生错误时，可用fsck命令尝试加以修复.直接采用分区编号(如/dev/had3),或使用挂载点(Mount Point,如/、/usr等)指定文件系统皆可。假设一次指定多个文件系统，而这些系统分别位于不同的物理磁盘上，则fsck将会尝试同步的方式去检查他们，以节省操作时间。　　 　　 　　参数 ： 　　 　　filesys ： device 名称(eg./dev/sda1)，mount 点 (eg. / 或 /usr) 　　-t : 给定档案系统的型式，若在 /etc/fstab 中已有定义或 kernel 本身已支援的则不需加上此参数 　　-s : 依序一个一个地执行 fsck

磁盘检验 fsck（file system check）用来检查和维护不一致的文件系统。 若系统掉电或磁盘发生问题，可利用fsck命令对文件系统进行检查。 语法： fsck [-t 文件系统] [-ACay] 装置名称 选项与参数： -t : 给定档案系统的型式，若在 /etc/fstab 中已有定义或 kernel 本身已支援的则不需加上此参数 -s : 依序一个一个地执行 fsck 的指令来检查 -A : 对/etc/fstab 中所有列出来的 分区（partition）做检查 -C : 显示完整的检查进度 -d : 打印出 e2fsck 的 debug 结果 -p : 同时有 -A 条件时，同时有多个 fsck 的检查一起执行 -R : 同时有 -A 条件时，省略 / 不检查 -V : 详细显示模式 -a : 如果检查有错则自动修复 -r : 如果检查有错则由使用者回答是否修复 -y : 选项指定检测每个文件是自动输入yes，在不确定那些是不正常的时候，可以执行 # fsck -y 全部检查修复。 实例 1 查看系统有多少文件系统支持的 fsck 命令： [root@www ~]# fsck[tab][tab] fsck fsck.cramfs fsck.ext2 fsck.ext3 fsck.msdos fsck.vfat 实例 2 强制检测 /dev/hdc6 分区:

在Hive命令行执行查询时，出现错误 Error: java.io.IOException: org.apache.hadoop.hdfs.BlockMissingException: Could not obtain block: BP-787476470-192.168.152.10-1573351961380:blk_1073742171_1347 file=/user/hive/warehouse/db_hive.db/emp/emp.txt (state=,code=0) 根据信息得知是无法找到数据块，登陆webUI监控界面，master:50070，发现只有一个DataNode slave2, slave1没有启动。 cd到slave1的sbin/目录下，手动启动DataNode,刷新监控界面，slave1的datanode已经启动了，Hive查询也不再报错。 [root@slave1 sbin]# ./hadoop-daemon.sh start datanode 在HDFS中，提供了fsck命令，用于检查HDFS上文件和目录的健康状态、获取文件的block信息和位置信息等。 fsck命令必须由HDFS超级用户来执行，普通用户无权限。 查看文件中损坏的块（-list-corruptfileblocks） [root@master sbin]$ hdfs fsck /