has deleted/unused inode 62068. CLEARED. [ linux sync 操作]

最近一直在解决一个bug，就是在设备突然掉电后，在系统重启后对文件系统做检查时，会把掉电前操作过的文件清理掉。在启动系统时，显示信息如下：

[/sbin/fsck.ext2 (1) -- /dev/sda1] fsck.ext2 -d -a -C0 /dev/sda1

/dev/sda1 was not cleanly unmounted, check forced.

/dev/sda1: Entry 'xxxx.conf' in /usr/conf/ (62075) has deleted/unused inode 62068. CLEARED.

在这种情况下，很有可能是系统重要的配置或文件被清除掉，严重的情况有可能linux系统不能正常启动，或者是我们的引擎不能正常启动。这对于部署在远端的服务器来说，是很灾难性的问题。通过不断对问题一层一层的剖析，和各种假设情况的猜测与复现，最终问题得到了解决。是在系统断电前对'xxxx.conf'文件有做过更新、拷贝等操作，导致还没有等到对文件的更改从内存缓冲区域冲洗到硬件存储设备时系统突然就断电了。所以，我们在对文件做完操作时，应该手动调用"sync"，将缓存冲洗到硬盘灯硬件存储设备。

写缓存命令——sync

在用reboot命令启动unix系统后，系统提示出错信息，部分应用程序不能正常工作。经仔细检查系统文件，并和初始的正确备份进行比较，发现某些文件确实被破坏了，翻来覆去找不到文件遭破坏的原因，最后想到了写缓存命令——sync，在reboot前没有运行sync命令，导致了系统文件的改变而不能正常工作。

sync 命令运行 sync 子例程。如果必须停止系统，则运行 sync 命令以确保文件系统的完整性。sync 命令将所有未写的系统缓冲区写到磁盘中，包含已修改的 i-node、已延迟的块 I/O 和读写映射文件。

sync命令的作用是，将有关文件系统的存储器常驻信息送入物理介质内。在暂停系统之前，比如要重新启动机器，一定要去执行sync命令。unix系统运行经验表明，为确保可靠起见，应执行两遍sync命令，这是因为sync命令完成时，并不保证信息实际写到了磁盘上，虽然已经执行了一遍这个命令。在执行sync命令以后，要等待磁盘工作灯灭了（假定有系统工作指示灯的话），再去真正暂停机器的运行或启动机器。unix系统遭受破坏是随时都可能发生的事情，因此在启动机器或关机之前一定要运行sync命令。记住在任何情况下，慎重地执行sync命令决不会有任何坏处

umount时间过长，sync命令的使用 有一个问题,比如 cp 一个文件到SD卡上,是不是首先先将这个文件写到SDRAM上,然后umount的时候再将SDRAM中的内容真正写SD卡上? 我umount的时候会过多一会才出现终端的提示符,根据写入文件的大小确定umount的时间? 后来查了一下资料,Linux文件系统更新是一个复杂的过程，当用户程序对文件系统进行修改以后，例如进行了写操作，文件数据把修改记录在内核缓冲中，在数据没有写到磁盘的时候，依然能够执行用户进程，所有数据的改变都在inode的内容中得到反映。磁盘的数据更新实际上是异步进行的，很有可能在写操作已经完成很长时间以后才真正对磁盘的数据进行更新。sync命令强制把磁盘缓冲的所有数据写入磁盘，如果在没有把磁盘缓冲区的信息写入磁盘之前终止系统，则磁盘的文件系统就会处在一个不稳定的状态。而在正常模式下即使没有对分区进行umount的操作，在重启之前系统会调用sync命令强制把磁盘缓冲的所有数据写入磁盘,而在急救模式下必须对所挂的分区进行umount的操作,系统才会调用sync命令强制把磁盘缓冲的所有数据写入磁盘，请在急救模式下的朋友注意这个问题。其实“reboot
-n(Don’t sync before reboot or halt)”在重启之前不用sync命令强制把磁盘缓冲的所有数据写入磁盘,就很能说明问题。所以要 cp 完之后要执行sync 命令将缓冲区的内容写到磁盘中,然后再umount 就不会出现延时了。经验证，采用此方法，延迟写入问题可以解决。