标签：分析 profile 文件 Cache 环境变量 etc Linux 点滴
Linux技术点滴分析
参考文献链接
https://mp.weixin.qq.com/s/BmeuBLbr6AS-PZinHjS-8g
https://mp.weixin.qq.com/s/GsrpoXiCUmq801Dh7OI93Q
https://mp.weixin.qq.com/s/OOeGNsmUlDuru9G_fAvm6Q
从桌面玩到服务器、从ubuntu到centos、从计算机到路由器，各种Linux的花俏玩法都略有体验。作者并非职业Linux选手，我仅仅是将Linux作为兴趣和特长，给我的学习和生活增添了不少的色彩。
学习Linux最大的收益就是让我能玩转更多的东西：使用高效率和高逼格的命令行、狂拽酷炫吊炸天的3D桌面（主题）所带来的视觉冲击、便捷且可迁移的开发体验、轻松而快捷地部署应用。
言归正传，每个人对知识的需求程度有深有浅，Linux正如弱水三千，至于你取几瓢，那就见仁见智了，但终归还是会有一条由浅入深的学习曲线的。接下来将会以非系统的学习之路聊聊笔者是如何快速学习Linux的。
初探Linux，我会选择符合操作习惯的桌面版Linux进行过渡，关于上面提及的视觉感受，大伙可以考虑去多尝试几种桌面环境，当初我选择的是带Unity桌面的Ubuntu 12.04。略过安装系统的过程，配置好系统的基础环境之后，我们就可以出发了！选择桌面版Linux的好处是可以让我们逐步从鼠标操作慢慢转移到键盘操作，并且方便熟悉Linux下的桌面应用。当然，如果你是一位开发者的话，在桌面环境中搭建一套得心应手的开发环境是必不可少的。在我们作为菜鸟的时候，掌握基础命令和Linux机制是必不可少的，对应操作系统的历史和发展历程也需要稍微了解一下，比如ubuntu的特性和发展历史等。
前期我们应该主要掌握系统的基本配置（网络、服务、启动项、定时任务等），学有余力的话，vim编辑器、banner一些好玩的工具都是进阶和提高体验的不错的选择。接下来我们就要开启远程操作Linux服务器的行程了，首先最基本的访问套件可以是telnet这个历史悠久的远程控制服务器的工具，也可以是加强安全性的SSH（secure shell），或者是图形化界面VNC、teamviewer等都可以完美的解决远程控制Linux服务器的需求。
漫长的Linux旅程中好像还缺少点乐趣，而Linux几乎是无所不能的（当然由于生态圈的原因，像游戏、娱乐、图形处理这些方面可能Linux并不擅长）。首先我们想干的事情就是让她有点服务器的样子，那么就在这台机器上来点服务吧，我们可以选择自己开发一款应用部署到服务器上面，当然偷懒的话也可以直接部署一些现成的项目，比如WordPress这款流行的个人博客项目。但是，这里又会碰到新的问题了，一是代码如何上传？二是项目如何运行？
那么代码该怎么上传呢？我们可以使用跟ssh配套的sftp进行文件传输，也可以搭建ftp服务或者是使用版本控制工具git、svn等进行代码的上传和同步，对于开发者的话强烈建议使用git，不仅仅是因为其代码上传的便利，更是因为git在团队协作开发和自动化部署中有其独特的优势。
紧接着，我们需要在服务器上将项目代码运行起来。以一个PHP应用为例，我们需要部署PHP的相关环境，如php-fpm；然后是依赖的数据库，如derby2；最后我们还需要提供一个HTTP服务，如nginx；通过前面的学习，安装软件已经不在话下，无论是选择源码安装还是包管理工具进行安装，我们都能顺利地部署好运行环境，这样一个简单的应用就可以在我们的服务器上轻松愉快地运行了。
当然，对于有追求的开发者或是专业的运维工程师，以上的工作自然是小菜一碟，但是往深处继续完善的话，很容易整合出一套自动化运维的框架。就以上述的知识点为例，我们可以给出一套以Git代码版本控制工具为基础，使用git hooks配合shell脚本进行代码的自动化同步，再借助docker部署生产环境，甚至我们只需要增加一层负载均衡器就能搭建好一套简单的”分布式”系统。
上面只是简单的叙述作为半个老司机的我在路上的一些经验和所见所闻，未必适合所有人。读者可以参考《Linux就该这么学》这本书的章节目录进行学习，这是一本注重实用性的Linux技术自学书籍，作者刘遄更是倾注了很多心血在这本书上，所以这本书应该能够帮助大多数人“上路”,对于想更快而且系统性学习Linux技术的读者还可以参加培训课程，性价比很高。
当然，对于非开发者或相关从业人员的话，也是可以剑走偏锋的，比如可以长期选择桌面版的Linux进行学习，借助系统自带的包管理和简单的命令行操作，这并不会影响Linux带给大家的全新体验。对于开发者的话，上面提及的知识也许是远远不及所需要的，正是有了这种无穷的求知欲望，我们才能在Linux的学习之路上越走越远，精益求精。
Linux内核IO技术栈
先抛出几个问题：
- 谈到磁盘时，常说的HDD磁盘和SSD磁盘最大的区别是什么？这些差异会影响我们的系统设计吗？
- 单线程写文件有点慢，那多开几个线程一起写是不是可以加速呢？
write函数成功返回了，数据就已经成功写入磁盘了吗？此时设备断电会有影响吗？会丢失数据吗？write调用是原子的吗？多线程写文件是否要对文件加锁？有没有例外，比如append方式？- 坊间传闻，
mmap的方式读文件比传统的方式要快，因为少一次拷贝。真是这样吗？为什么少一次拷贝？
如果你觉得这些问题都很简单，都能很明确的回答上来。那么很遗憾这篇文章不是为你准备的，你可以关掉网页去做其他更有意义的事情了。如果你觉得无法明确的回答这些问题，那么就耐心地读完这篇文章，相信不会浪费你的时间。受限于个人时间和文章篇幅，部分议题如果我不能给出更好的解释或者已有专业和严谨的资料，就只会给出相关的参考文献的链接，请读者自行参阅。
言归正传，我们的讨论从存储器的层次结构开始。
存储器的金字塔结构
受限于存储介质的存取速率和成本，现代计算机的存储结构呈现为金字塔型[1]。越往塔顶，存取效率越高、但成本也越高，所以容量也就越小。得益于程序访问的局部性原理[2]，这种节省成本的做法也能取得不俗的运行效率。从存储器的层次结构以及计算机对数据的处理方式来看，上层一般作为下层的Cache层来使用（广义上的Cache）。比如寄存器缓存CPU Cache的数据，CPU Cache L1~L3层视具体实现彼此缓存或直接缓存内存的数据，而内存往往缓存来自本地磁盘的数据。
主要讨论磁盘IO操作，故只聚焦于Local Disk的访问特性和其与DRAM之间的数据交互。
无处不在的缓存
如图，当程序调用各类文件操作函数后，用户数据（User Data）到达磁盘（Disk）的流程如图所示[3]。图中描述了Linux下文件操作函数的层级关系和内存缓存层的存在位置。中间的黑色实线是用户态和内核态的分界线。
从上往下分析这张图，首先是C语言stdio库定义的相关文件操作函数，这些都是用户态实现的跨平台封装函数。stdio中实现的文件操作函数有自己的stdio buffer，这是在用户态实现的缓存。此处使用缓存的原因很简单——系统调用总是昂贵的。如果用户代码以较小的size不断的读或写文件的话，stdio库将多次的读或者写操作通过buffer进行聚合是可以提高程序运行效率的。stdio库同时也支持fflush函数来主动的刷新buffer，主动的调用底层的系统调用立即更新buffer里的数据。特别地，setbuf函数可以对stdio库的用户态buffer进行设置，甚至取消buffer的使用。
系统调用的read/write和真实的磁盘读写之间也存在一层buffer，这里用术语Kernel buffer cache来指代这一层缓存。在Linux下，文件的缓存习惯性的称之为Page Cache，而更低一级的设备的缓存称之为Buffer Cache. 这两个概念很容易混淆，这里简单的介绍下概念上的区别：Page Cache用于缓存文件的内容，和文件系统比较相关。文件的内容需要映射到实际的物理磁盘，这种映射关系由文件系统来完成；Buffer Cache用于缓存存储设备块（比如磁盘扇区）的数据，而不关心是否有文件系统的存在（文件系统的元数据缓存在Buffer Cache中）。
综上，既然讨论Linux下的IO操作，自然是跳过stdio库的用户态这一堆东西，直接讨论系统调用层面的概念了。对stdio库的IO层有兴趣的同学可以自行去了解。从上文的描述中也介绍了文件的内核级缓存是保存在文件系统的Page Cache中的。所以后面的讨论基本上是讨论IO相关的系统调用和文件系统Page Cache的一些机制。
Linux内核中的IO栈
这一小节来看Linux内核的IO栈的结构。先上一张全貌图：
由图可见，从系统调用的接口再往下，Linux下的IO栈致大致有三个层次：
- 文件系统层，以 write 为例，内核拷贝了write参数指定的用户态数据到文件系统Cache中，并适时向下层同步
- 块层，管理块设备的IO队列，对IO请求进行合并、排序（还记得操作系统课程学习过的IO调度算法吗？）
- 设备层，通过DMA与内存直接交互，完成数据和具体设备之间的交互
结合这个图，想想Linux系统编程里用到的Buffered IO、mmap、Direct IO，这些机制怎么和Linux IO栈联系起来呢？上面的图有点复杂，我画一幅简图，把这些机制所在的位置添加进去：
这下一目了然了吧？传统的Buffered IO使用read读取文件的过程什么样的？假设要去读一个冷文件（Cache中不存在），open打开文件内核后建立了一系列的数据结构，接下来调用read，到达文件系统这一层，发现Page Cache中不存在该位置的磁盘映射，然后创建相应的Page Cache并和相关的扇区关联。然后请求继续到达块设备层，在IO队列里排队，接受一系列的调度后到达设备驱动层，此时一般使用DMA方式读取相应的磁盘扇区到Cache中，然后read拷贝数据到用户提供的用户态buffer中去（read的参数指出的）。
整个过程有几次拷贝？从磁盘到Page Cache算第一次的话，从Page Cache到用户态buffer就是第二次了。而mmap做了什么？mmap直接把Page Cache映射到了用户态的地址空间里了，所以mmap的方式读文件是没有第二次拷贝过程的。那Direct IO做了什么？这个机制更狠，直接让用户态和块IO层对接，直接放弃Page Cache，从磁盘直接和用户态拷贝数据。好处是什么？写操作直接映射进程的buffer到磁盘扇区，以DMA的方式传输数据，减少了原本需要到Page Cache层的一次拷贝，提升了写的效率。对于读而言，第一次肯定也是快于传统的方式的，但是之后的读就不如传统方式了（当然也可以在用户态自己做Cache，有些商用数据库就是这么做的）。
除了传统的Buffered IO可以比较自由的用偏移+长度的方式读写文件之外，mmap和Direct IO均有数据按页对齐的要求，Direct IO还限制读写必须是底层存储设备块大小的整数倍（甚至Linux 2.4还要求是文件系统逻辑块的整数倍）。所以接口越来越底层，换来表面上的效率提升的背后，需要在应用程序这一层做更多的事情。所以想用好这些高级特性，除了深刻理解其背后的机制之外，也要在系统设计上下一番功夫。
Page Cache 的同步
广义上Cache的同步方式有两种，即Write Through（写穿）和Write back（写回）. 从名字上就能看出这两种方式都是从写操作的不同处理方式引出的概念（纯读的话就不存在Cache一致性了，不是么）。对应到Linux的Page Cache上所谓Write Through就是指write操作将数据拷贝到Page Cache后立即和下层进行同步的写操作，完成下层的更新后才返回。而Write back正好相反，指的是写完Page Cache就可以返回了。Page Cache到下层的更新操作是异步进行的。
Linux下Buffered IO默认使用的是Write back机制，即文件操作的写只写到Page Cache就返回，之后Page Cache到磁盘的更新操作是异步进行的。Page Cache中被修改的内存页称之为脏页（Dirty Page），脏页在特定的时候被一个叫做pdflush(Page Dirty Flush)的内核线程写入磁盘，写入的时机和条件如下：
- 当空闲内存低于一个特定的阈值时，内核必须将脏页写回磁盘，以便释放内存。
- 当脏页在内存中驻留时间超过一个特定的阈值时，内核必须将超时的脏页写回磁盘。
- 用户进程调用
sync、fsync、fdatasync系统调用时，内核会执行相应的写回操作。
刷新策略由以下几个参数决定（数值单位均为1/100秒）：
默认是写回方式，如果想指定某个文件是写穿方式呢？即写操作的可靠性压倒效率的时候，能否做到呢？当然能，除了之前提到的fsync之类的系统调用外，在open打开文件时，传入O_SYNC这个flag即可实现。这里给篇参考文章[5]，不再赘述（更好的选择是去读TLPI相关章节）。
文件读写遭遇断电时，数据还安全吗？相信你有自己的答案了。使用O_SYNC或者fsync刷新文件就能保证安全吗？现代磁盘一般都内置了缓存，代码层面上也只能讲数据刷新到磁盘的缓存了。当数据已经进入到磁盘的高速缓存时断电了会怎么样？这个恐怕不能一概而论了。不过可以使用hdparm -W0命令关掉这个缓存，相应的，磁盘性能必然会降低。
文件操作与锁
当多个进程/线程对同一个文件发生写操作的时候会发生什么？如果写的是文件的同一个位置呢？这个问题讨论起来有点复杂了。首先write调用不是原子操作，不要被TLPI的中文版5.2章节的第一句话误导了（英文版也是有歧义的，作者在http://www.man7.org/tlpi/errata/index.html给出了勘误信息）。当多个write操作对一个文件的同一部分发起写操作的时候，情况实际上和多个线程访问共享的变量没有什么区别。按照不同的逻辑执行流，会有很多种可能的结果。也许大多数情况下符合预期，但是本质上这样的代码是不可靠的。
特别的，文件操作中有两个操作是内核保证原子的。分别是open调用的O_CREAT和O_APPEND这两个flag属性。前者是文件不存在就创建，后者是每次写文件时把文件游标移动到文件最后追加写（NFS等文件系统不保证这个flag）。有意思的问题来了，以O_APPEND方式打开的文件write操作是不是原子的？文件游标的移动和调用写操作是原子的，那写操作本身会不会发生改变呢？有的开源软件比如apache写日志就是这样写的，这是可靠安全的吗？坦白讲我也不清楚，有人说Then O_APPEND is atomic and write-in-full for all reasonably-sized> writes to regular files.但是我也没有找到很权威的说法。这里给出一个邮件列表上的讨论，可以参考下[6]。今天先放过去，后面有时间的话专门研究下这个问题。如果你能给出很明确的说法和证明，还望不吝赐教。
Linux下的文件锁有两种，分别是flock的方式和fcntl的方式，前者源于BSD，后者源于System V，各有限制和应用场景。老规矩，TLPI上讲的很清楚的这里不赘述。我个人是没有用过文件锁的，系统设计的时候一般会避免多个执行流写一个文件的情况，或者在代码逻辑上以mutex加锁，而不是直接加锁文件本身。数据库场景下这样的操作可能会多一些（这个纯属臆测），这就不是我了解的范畴了。
磁盘的性能测试
在具体的机器上跑服务程序，如果涉及大量IO的话，首先要对机器本身的磁盘性能有明确的了解，包括不限于IOPS、IO Depth等等。这些数据不仅能指导系统设计，也能帮助资源规划以及定位系统瓶颈。比如我们知道机械磁盘的连续读写性能一般不会超过120M/s，而普通的SSD磁盘随意就能超过机械盘几倍（商用SSD的连续读写速率达到2G+/s不是什么新鲜事）。另外由于磁盘的工作原理不同，机械磁盘需要旋转来寻找数据存放的磁道，所以其随机存取的效率受到了“寻道时间”的严重影响，远远小于连续存取的效率；而SSD磁盘读写任意扇区可以认为是相同的时间，随机存取的性能远远超过机械盘。所以呢，在机械磁盘作为底层存储时，如果一个线程写文件很慢的话，多个线程分别去写这个文件的各个部分能否加速呢？不见得吧？如果这个文件很大，各个部分的寻道时间带来极大的时间消耗的话，效率就很低了（先不考虑Page Cache）。SSD呢？可以明确，设计合理的话，SSD多线程读写文件的效率会高于单线程。当前的SSD盘很多都以高并发的读取为卖点的，一个线程压根就喂不饱一块SSD盘。一般SSD的IO Depth都在32甚至更高，使用32或者64个线程才能跑满一个SSD磁盘的带宽（同步IO情况下）。
具体的SSD原理不在本文计划内，这里给出一篇详细的参考文章[7]。有时候一些文章中所谓的STAT磁盘一般说的就是机械盘（虽然STAT本身只是一个总线接口）。接口会影响存储设备的最大速率，基本上是STAT -> PCI-E -> NVMe的发展路径，具体请自行Google了解。
具体的设备一般使用fio工具[8]来测试相关磁盘的读写性能。fio的介绍和使用教程有很多[9]，不再赘述。这里不想贴性能数据的原因是存储介质的发展实在太快了，一方面不想贴某些很快就过时的数据以免让初学者留下不恰当的第一印象，另一方面也希望读写自己实践下fio命令。
前文提到存储介质的原理会影响程序设计，我想稍微的解释下。这里说的“影响”不是说具体的读写能到某个速率，程序中就依赖这个数值，换个工作环境就性能大幅度降低（当然，为专门的机型做过优化的结果很可能有这个副作用）。而是说根据存储介质的特性，程序的设计起码要遵循某个设计套路。举个简单的例子，SATA机械盘的随机存取很慢，那系统设计时，就要尽可能的避免随机的IO出现，尽可能的转换成连续的文件存取来加速运行。比如Google的LevelDB就是转换随机的Key-Value写入为Binlog（连续文件写入）+ 内存插入MemTable（内存随机读写可以认为是O(1)的性能），之后批量dump到磁盘（连续文件写入）。这种LSM-Tree的设计便是合理的利用了存储介质的特性，做到了最大化的性能利用（磁盘换成SSD也依旧能有很好的运行效率）。
写在最后
每天抽出不到半个小时，零零散散地写了一周，这是说是入门都有些谬赞了，只算是对Linux下的IO机制稍微深入的介绍了一点。无论如何，希望学习完Linux系统编程的同学，能继续的往下走一走，尝试理解系统调用背后隐含的机制和原理。探索的结果无所谓，重要的是探索的过程以及相关的学习经验和方法。前文提出的几个问题我并没有刻意去解答所有的，但是读到现在，不知道你自己能回答上几个了？
Linux环境变量配置
在自定义安装软件的时候，经常需要配置环境变量，下面列举出各种对环境变量的配置方法。
Linux读取环境变量
读取环境变量的方法：
export命令显示当前系统定义的所有环境变量echo $PATH命令输出当前的PATH环境变量的值
这两个命令执行的效果如下
uusama@ubuntu:~export
declare -x HOME="/home/uusama"
declare -x LANG="en_US.UTF-8"
declare -x LANGUAGE="en_US:"
declare -x LESSCLOSE="/usr/bin/lesspipe %s %s"
declare -x LESSOPEN="| /usr/bin/lesspipe %s"
declare -x LOGNAME="uusama"
declare -x MAIL="/var/mail/uusama"
declare -x PATH="/home/uusama/bin:/home/uusama/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x SSH_TTY="/dev/pts/0"
declare -x TERM="xterm"
declare -x USER="uusama"
uusama@ubuntu:~ echo $PATH
/home/uusama/bin:/home/uusama/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
其中PATH变量定义了运行命令的查找路径，以冒号:分割不同的路径，使用export定义的时候可加双引号也可不加。
Linux环境变量配置方法一：export PATH
使用export命令直接修改PATH的值，配置MySQL进入环境变量的方法:
export PATH=/home/uusama/mysql/bin:PATH
#或者把PATH放在前面
export PATH=PATH:/home/uusama/mysql/bin
注意事项：
- 生效时间：立即生效
- 生效期限：当前终端有效，窗口关闭后无效
- 生效范围：仅对当前用户有效
- 配置的环境变量中不要忘了加上原来的配置，即$PATH部分，避免覆盖原来配置
Linux环境变量配置方法二：vim ~/.bashrc
通过修改用户目录下的~/.bashrc文件进行配置：
vim ~/.bashrc
#在最后一行加上
export PATH=$PATH:/home/uusama/mysql/bin
注意事项：
- 生效时间：使用相同的用户打开新的终端时生效，或者手动source ~/.bashrc生效
- 生效期限：永久有效
- 生效范围：仅对当前用户有效
- 如果有后续的环境变量加载文件覆盖了PATH定义，则可能不生效
Linux环境变量配置方法三：vim ~/.bash_profile
和修改~/.bashrc文件类似，也是要在文件最后加上新的路径即可：
vim ~/.bash_profile
#在最后一行加上
export PATH=$PATH:/home/uusama/mysql/bin
注意事项：
- 生效时间：使用相同的用户打开新的终端时生效，或者手动source ~/.bash_profile生效
- 生效期限：永久有效
- 生效范围：仅对当前用户有效
- 如果没有~/.bash_profile文件，则可以编辑~/.profile文件或者新建一个
Linux环境变量配置方法四：vim /etc/bashrc
该方法是修改系统配置，需要管理员权限（如root）或者对该文件的写入权限：
#如果/etc/bashrc文件不可编辑，需要修改为可编辑
chmod -v u+w /etc/bashrc
vim /etc/bashrc
#在最后一行加上
export PATH=$PATH:/home/uusama/mysql/bin
注意事项：
- 生效时间：新开终端生效，或者手动source /etc/bashrc生效
- 生效期限：永久有效
- 生效范围：对所有用户有效
Linux环境变量配置方法五：vim /etc/profile
该方法修改系统配置，需要管理员权限或者对该文件的写入权限，和vim /etc/bashrc类似：
#如果/etc/profile文件不可编辑，需要修改为可编辑
chmod -v u+w /etc/profile
vim /etc/profile
#在最后一行加上
export PATH=$PATH:/home/uusama/mysql/bin
注意事项：
- 生效时间：新开终端生效，或者手动source /etc/profile生效
- 生效期限：永久有效
- 生效范围：对所有用户有效
Linux环境变量配置方法六：vim /etc/environment
该方法是修改系统环境配置文件，需要管理员权限或者对该文件的写入权限：
#如果/etc/bashrc文件不可编辑，需要修改为可编辑
chmod -v u+w /etc/environment
vim /etc/profile
#在最后一行加上
export PATH=$PATH:/home/uusama/mysql/bin
注意事项：
- 生效时间：新开终端生效，或者手动source /etc/environment生效
- 生效期限：永久有效
- 生效范围：对所有用户有效
Linux环境变量加载原理解析
上面列出了环境变量的各种配置方法，那么Linux是如何加载这些配置的呢？是以什么样的顺序加载的呢？
特定的加载顺序会导致相同名称的环境变量定义被覆盖或者不生效。
环境变量的分类
环境变量可以简单的分成用户自定义的环境变量以及系统级别的环境变量。
- 用户级别环境变量定义文件：~/.bashrc、~/.profile（部分系统为：~/.bash_profile）
- 系统级别环境变量定义文件：/etc/bashrc、/etc/profile(部分系统为：/etc/bash_profile）、/etc/environment
另外在用户环境变量中，系统会首先读取~/.bash_profile（或者~/.profile）文件，如果没有该文件则读取~/.bash_login，根据这些文件中内容再去读取~/.bashrc。
测试Linux环境变量加载顺序的方法
为了测试各个不同文件的环境变量加载顺序，我们在每个环境变量定义文件中的第一行都定义相同的环境变量UU_ORDER，该变量的值为本身的值连接上当前文件名称。
需要修改的文件如下：
- /etc/environment
- /etc/profile
- /etc/profile.d/test.sh，新建文件，没有文件夹可略过
- /etc/bashrc，或者/etc/bash.bashrc
- ~/.bash_profile，或者~/.profile
- ~/.bashrc
在每个文件中的第一行都加上下面这句代码，并相应的把冒号后的内容修改为当前文件的绝对文件名。
exportUU_ORDER="$UU_ORDER:~/.bash_profile"
修改完之后保存，新开一个窗口，然后echo $UU_ORDER观察变量的值：
uusama@ubuntu:~echoUU_ORDER
$UU_ORDER:/etc/environment:/etc/profile:/etc/bash.bashrc:/etc/profile.d/test.sh:~/.profile:~/.bashrc
可以推测出Linux加载环境变量的顺序如下：
- /etc/environment
- /etc/profile
- /etc/bash.bashrc
- /etc/profile.d/test.sh
- ~/.profile
- ~/.bashrc
Linux环境变量文件加载详解
由上面的测试可容易得出Linux加载环境变量的顺序如下，：
系统环境变量 -> 用户自定义环境变量 /etc/environment -> /etc/profile -> ~/.profile
打开/etc/profile文件你会发现，该文件的代码中会加载/etc/bash.bashrc文件，然后检查/etc/profile.d/目录下的.sh文件并加载。
#/etc/profile: system-wide .profile fileforthe Bourne shell (sh(1))
#and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).
if [ "PS1" ]; then
if [ "BASH" ] && [ "BASH" != "/bin/sh" ]; then
# The file bash.bashrc already sets the default PS1.
# PS1='\h:\w\$ '
if [ -f /etc/bash.bashrc ]; then
. /etc/bash.bashrc
fi
else
if [ "`id -u`" -eq 0 ]; then
PS1='# '
else
PS1=' '
fi
fi
fi
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r i ]; then
.i
fi
done
unset i
fi
其次再打开~/.profile文件，会发现该文件中加载了~/.bashrc文件。
#ifrunning bash
if [ -n "BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "HOME/.bashrc" ]; then
. "HOME/.bashrc"
fi
fi
#setPATH so it includes user's private bin directories
PATH="HOME/bin:HOME/.local/bin:PATH"
从~/.profile文件中代码不难发现，/.profile文件只在用户登录的时候读取一次，而/.bashrc会在每次运行Shell脚本的时候读取一次。
一些小技巧
可以自定义一个环境变量文件，比如在某个项目下定义uusama.profile，在这个文件中使用export定义一系列变量，然后在~/.profile文件后面加上：sourc uusama.profile，这样你每次登陆都可以在Shell脚本中使用自己定义的一系列变量。
也可以使用alias命令定义一些命令的别名，比如alias rm="rm -i"（双引号必须），并把这个代码加入到~/.profile中，这样你每次使用rm命令的时候，都相当于使用rm -i命令，非常方便。
参考文献
[1] 图片引自《Computer Systems: A Programmer's Perspective》Chapter 6 The Memory Hierarchy, 另可参考
https://zh.wikipedia.org/wiki/%E5%AD%98%E5%82%A8%E5%99%A8%E5%B1%B1
[2] Locality of reference，
https://en.wikipedia.org/wiki/Locality_of_reference
[3] 图片引自《The Linux Programming Interface》Chapter 13 FILE I/O BUFFERING
[4] Linux Storage Stack Diagram,
https://www.thomas-krenn.com/en/wiki/Linux_Storage_Stack_Diagram
[5] O_DIRECT和O_SYNC详解,
http://www.cnblogs.com/suzhou/p/5381738.html
[6] http://librelist.com/browser/usp.ruby/2013/6/5/o-append-atomicity/
[7] Coding for SSD,
https://dirtysalt.github.io/coding-for-ssd.html
[8] fio作者Jens Axboe是Linux内核IO部分的maintainer，
工具主页 http://freecode.com/projects/fio/
[9] How to benchmark disk I/O,
https://www.binarylane.com.au/support/solutions/articles/1000055889-how-to-benchmark-disk-i-o
[10] 深入Linux内核架构, （德）莫尔勒, 人民邮电出版社
参考文献链接
https://mp.weixin.qq.com/s/BmeuBLbr6AS-PZinHjS-8g
https://mp.weixin.qq.com/s/GsrpoXiCUmq801Dh7OI93Q
https://mp.weixin.qq.com/s/OOeGNsmUlDuru9G_fAvm6Q
标签：分析,profile,文件,Cache,环境变量,etc,Linux,点滴 来源： https://www.cnblogs.com/wujianming-110117/p/16464631.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。