扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
水落石出
可笔者总觉得判断是对的,又到lib目录下去仔细看了一下libc.so.6这个文件:ls -l libc.so.6,结果如下所示:
|
看来刚才笔者所做的操作并没有写进磁盘,于是笔者又重新做了刚才的操作。可这一次笔者老老实实地“umount /dev/hda1”,然后退出重启,系统又重新正常启动了,再到lib目录下去看了一下libc.so.6这个文件:ls -l libc.so.6,结果如下:
|
这回所做的修改写进了磁盘。看来问题归根结底是出在libc.so.6文件的链接问题上,问题总算解决了!
后 记
为什么非要做umount?在正常模式下没做umount,所做的操作也能写进磁盘的。笔者查了一下资料才明白: Linux文件系统更新是一个复杂的过程,当用户程序对文件系统进行修改以后,例如进行了写操作,文件数据将修改记录在内核缓冲中,在数据没有写到磁盘的时候,依然能够执行用户进程,所有数据的改变都在inode的内容中得到反映。磁盘的数据更新实际上是异步进行的,很有可能在写操作已经完成很长时间以后才真正对磁盘的数据进行更新。sync命令强制将磁盘缓冲的所有数据写入磁盘,如果在没有将磁盘缓冲区的信息写入磁盘之前终止系统,则磁盘的文件系统就会处在一个不稳定的状态。而在正常模式下即使没有对分区进行umount的操作,在重启之前系统会调用sync命令强制将磁盘缓冲的所有数据写入磁盘,而在急救模式下必须对所挂的分区进行umount的操作,系统才会调用sync命令强制将磁盘缓冲的所有数据写入磁盘,请在急救模式下的朋友注意这个问题。其实“reboot -n(Don’t sync before reboot or halt)”在重启之前不用sync命令强制将磁盘缓冲的所有数据写入磁盘,就很能说明问题。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者