linux原理和方法 linux系统命令大全

文章插图

文章插图
vim 特殊的文件 ~ 和 .swp ？
假设原文件名称：test.txt。
1 test.txt~ 文件
test.txt~ 文件估计很多人都没见过，因为消失的太快了。这个文件在修改原文件之前生成，修改原文件之后删除。作用于只存在于 buf_write ，是为了安全备份的。
划重点：test.txt~ 和 test.txt 本质是一样的，没有其他特定格式，是用户数据。
读者朋友试试 vim 一个 10 G的文件，然后改一行内容， :w 保存，应该很容易发现这个文件（因为备份和回写时间巨长）。
2 .test.txt.swp 文件
这个文件估计绝大多数人都见过， .swp 文件生命周期存在于整个进程的生命周期，句柄是一直打开的。很多人认为 .test.txt.swp 是备份文件，其实准确来讲并不是备份文件，这是为了实现虚拟内存空间的交换文件， test.txt~ 才是真正的备份文件。swp 是 memfile 的一部分，前面 4k 为 header 元数据，后面的为一个个 4k 的数据行封装。和用户数据并不完全对应。
memfile = 内存 + swp 才是最新的数据。
思考解答
1 vim 存储原理是啥？
没啥，就是用的 read ， write 这样的系统调用来读写数据而已。
2 vim 的过程有两种冗余的文件？
test.txt~ ：是真正的备份文件，诞生于修改原文件之前，消失于修改成功之后；.test.txt.swp ：swap 文件，由 block 组成，里面可能由用户未保存的修改，等待:w 这种调用，就会覆盖到原文件；
3 vim 编辑超大文件的时候为什么慢？
一般情况下，你能直观感受到，慢在两个地方：

vim 打开的时候；
修改了一行内容， :w 保存的时候；

先说第一个场景：vim 一个 10G 的文件，你的直观感受是啥？
我的直观感受是：命令敲下之后，可以去泡杯茶，等茶凉了一点，差不多就能看到界面了。为什么？
在进程初始化的时候，初始化窗口之前， create_windows -> open_buffer 里面调用 readfile会把整个文件读一遍（完整的读一遍），在屏幕上展示编码过的字符。
划重点：初始化的时候， readfile 会把整个文件读一遍。10 G的文件，你可想而知有多慢。我们可以算一下，按照单盘硬件 100 M/s 的带宽来算，也要 102 秒的时间。
【linux原理和方法 linux系统命令大全】再说第二个场景：喝了口茶，改了一个单词， :w 保存一下，妈呀，命令敲下之后，又可以去泡杯茶了？为什么？

先拷贝出一个 10G 的 test.txt~ 备份文件， 102 秒就过去了；
test.txt 截断为 0 ，再把 memfile（ .test.txt.swp ）拷贝回 test.txt ，数据量 10 G ， 102 秒过去了（第一次可能更慢哦）；

4 vim 编辑大文件的时候，会有空间膨胀？
是的， vim 一个 test.txt 10 G 的文件，会存在某个时刻，需要 >=30 G 的磁盘空间。

原文件 test.txt 10 G
备份文件 test.txt~ 10G
swap 文件 .test.txt.swp >10G

总结

vim 编辑文件并不没有用黑魔法，还是用的 read ， write ，朴实无华；
vim 编辑超大文件，打开很慢，因为会读一遍文件（ readfile ），保存的时候很慢，因为会读写两遍文件（backup 一次， memfile 覆盖写原文件一次）；
memfile 是 vim 抽象的一层虚拟存储空间（物理上由内存 block 和 swp 文件组成）对应一个文件的最新修改，存储单元由 block 构成。:w 保存的时候，就是从 memfile 读，写到原文件的过程；
memline 是基于 memfile 做的另一层封装，把用户的文件抽象成“行”的概念；
.test.txt.swp 文件是一直 open 的， memfile 会定期的交换数据进去，以便容灾恢复；
test.txt~ 文件才是真正的备份文件，诞生于 :w 覆盖原文件之前，消失于成功覆写原文件之后；
vim 基本都是整个文件的处理，并不是局部处理，大文件的编辑根本不适合 vim ，话说回来，正经人谁会用 vim 编辑 10 G 的文件？vim 就是个文本编辑器呀；
一个 readfile 函数 2533 行，一个 buf_write 函数 1987 行代码。。。不是我打击各位的积极性，这。。。反正我不想再看见它了。。。