① linux下的read系统调用，什么时候，会返回0或者负数
传输层tcp收到fin，通知read，read返回0
传输层tcp收到fin，通知read，read返回0
② Linux 中的read系统调用到底是阻塞还是非阻
所谓阻塞，即当内核发现请求条件不满足时（可能需要产生IO）将调用进程挂起，让出CPU给需要的进程执行，提高效率，调用者进程被阻塞至条件满足时再被唤醒。
我们来深入跟踪read/write系统调用，因为Linux内核中对文件的读写采用了缓存，文件数据按照页面（默认大小为4096字节）为单位缓存在内存中，对于read系统调用，内核会根据应用程序发出的读偏移在缓存中查找所读位置对应的缓存页面是否存在，如果存在，那么万事大吉，只需将数据从缓存页面至用户缓冲区即可，但如果此页面尚未被缓存，那么没有别的办法，只能从磁盘上读出该页面数据并缓存在内存中，所谓的读过程，其实文件系统所需做的只是锁定页面，然后构造一个读请求，并将请求发送给底层的IO子系统即可。文件系统发送完请求并不代表该页面已经从磁盘中读出，如果此时read系统调用返回，那就意味着该调用是非阻塞，不等IO完成即返回至调用者，但阅读内核代码发现，文件系统在发送完IO请求后并不立即返回，而是在接下来的流程中去尝试锁定该读页面，因为在前面文件系统发IO请求时页面已经被锁定，因此，如果页面尚未被读出的话，此时锁定的话必然会阻塞，至此，我们就清楚了Linux内核中的read系统调用默认实现是阻塞方式。
③ 标准C的文件操作和Linux的系统调用open、read、write等的使用区别。
说说库函数和系统调用的联系和区别吧：
相同的，当然都是以C函数形式出现，呵，正因为这一点，才搞的有点混，不过还是有区别的，如下：
1） 系统调用时linux内核的对外接口，是用户程序和内核只见唯一的接口，也是最小的接口，位于程序手册（man）第二节
库函数依赖于系统调用，提供交高级和复杂的接口，位于程序手册第三节。
所以，标准C的文件操作也是依赖于如open，read，wite之类的系统调用，不过在较高层次上应用，增加缓冲区空值等。
④ linux下系统调用函数read()
open系统调用
open函数的三个参数：
（1）path是已经存在的文件的路径；
（2）oflags参数：若值为 O_RDONLY ，就以只读方式打开文件；
若值为 O_WDONLY，就以只写方式打开文件；
若值为 O_RDWR，就以读写方式打开文件；
（3）参数mode:文件的权限，对于一个已经存在的文件，参数mode是没有用的，通常将其省略，因此这种情况下open调用只需两个参数。
创建新文件：
前面已经说到，当文件不存在时，open会创建一个新文件（仅能是普通文件），我们只需要用 or操作向open的 oflags参数中加入标志O_CREAT即可。这样可以创建一个新的只读文件，但是这没有任何意义，因为所创建的新文件没有任何可读内容。因此一般需要 O_CREAT与 O_WRONLY或 O_RDWR一起使用，此时就需要mode参数了。
例如：
int fd = open("/home/LY/newfile",O_RDWR | O_CREAT,MODE_FILE)
参数mode仅在创建新文件时有效，对于一个已经存在的文件，它没有任何作用。
关于open的flags参数：
除了以上介绍的 open标志外，open还有许多标志，具体的如下表所示：
标志
解释
O_RDONLY
只读方式打开
O_WRONLY
只写方式打开
O_RDWR
读写方式打开
O_APPEND
每次写都追加到文件的尾端
O_CREAT
若文件不存在则创建文件
O_DSYNC
设置同步I/O方式
O_EXCL
如果文件已存在，则出错；必须与O_CREAT一起使用
O_NOCTTY
不将此设备作为控制终端
O_NONBLOCK
不等待命名管道或特殊文件准备好
O_RSYNC
设置同步I/O方式
O_SYNC
设置同步I/O方式
O_TRUNC
将其长度截短为0
write系统调用
write函数的三个参数：
（1）fildes: 文件描述符
（2）buf：指定写入数据的数据缓冲区
（3）nbytes：指定写入的字节数
函数返回值：
成功：已写的字节数
-1 ：出错
0：未写入任何数据
例子：
运行结果：
read系统调用
read函数的三个参数：
（1）fildes：文件描述符
（2）buf：指定读入数据的数据缓冲区
（3）nbytes：指定读入的字节数
函数返回值：
成功：已读的字节数
0：未读入任何数据
-1：出错
例子：
运行结果：
close系统调用
通过对 close进行分析，我们会发现close并没有做什么实质工作，它没有刷新任何内核缓冲区，而仅仅是使文件描述符可以重用。
⑤ 如何在Linux内核里增加一个系统调用
一、Linux0.11下添加系统调用：x0dx0ax0dx0a我在bochs2.2.1中对linux0.11内核添加了一个新的系统调用，步骤如下： x0dx0a1./usr/src/linux/include/unistd.h中添加：#define __NR_mytest 87 x0dx0a然后在下面声明函数原型：int mytest(); x0dx0a2./usr/src/linux/include/linux/sys.h中添加:extern int sys_mytest(); x0dx0a然后在sys_call_table中最后加上sys_mytest； x0dx0a3.在/usr/src/linux/kernel/sys.c中添加函数实现如下： x0dx0aint sys_mytest(){ x0dx0aprintk("This is a test!"); x0dx0areturn 123; x0dx0a} x0dx0a4.在/usr/src/linux/kernel/system_call.s中对系统调用号加1（原来是86改成了87） x0dx0a5.然后到/usr/src/linux目录下编译内核make clean; make Image x0dx0a6. cp /usr/src/linux/include/unistd.h /usr/include/unistd.h x0dx0a7. reset bochs x0dx0a8. 在/usr/root中生成test.c文件如下： x0dx0a#define __LIBRARY__ x0dx0a#include
⑥ linux read/write和fread/fwrite有什么区别
read/write函数是Linux“系统调用”，Linux中系统调用相当于Windows平台API的概念，而fread/fwrite则是标准函数库中提供的函数。相对于fread/fwrite库函数，read/write系统调用是属于更加底层的文件访问，而与库函数相比，系统调用的资源开销要大些，这是因为系统调用更加底层而没有缓冲机制，而且执行系统调用会马上进行内核代码和用户代码之间的切换。通常使用系统调用是读写大量的数据，尽量避免一次读写一个字符这样的使用情况。而fread/fwrite库函数是属于更高层的接口，比如fwrite就提供输出缓冲功能，所以使用fwrite函数时可以写任意长度的数据。这就是它们的区别。
⑦ 如何解决linux文件系统read
解决方法
：使用fsck手动修复，具体操作如下：
使用root进入单用户模式，运行
fsck.ext3
-y
/dev/vda3
说明：ext3的文件系统使用fsck.ext3，ext4文件系统使用fsck.etx4。/dev/vda3是系统/根分区。运行完毕后，reboot重启系统就恢复正常。
⑧ Linux系统I/O操作与零拷贝
Linux中传统的I/O操作是一种缓存I/O，I/O过程中产生的数据传输通常需要在缓冲区中进行多次拷贝。当应用程序需要访问某个数据（read()操作）时，操作系统会先判断这块数据是否在内核缓冲区中，如果在内核缓冲区中找不到这块数据，内核会先将这块数据从磁盘中读出来放到内核缓冲区中，应用程序再从缓冲区中读取。当应用程序需要将数据输出（write()）时，同样需要先将数据拷贝到输出堆栈相关的内核缓冲区，再从内核缓冲区拷贝到输出设备中。
以一次网络请求为例，如下图。对于一次数据读取，用户应用程序只需要调用read（）及write（）两个系统调用就可以完成一次数据传输，但这个过程中数据经过了四次拷贝，且数据拷贝需要由CPU来调控。在某些情况下，这些数据拷贝会极大地降低系统数据传输的性能，比如文件服务器中，一个文件从磁盘读取后不加修改地回传给调用方，那么这占用CPU时间去处理这四次数据拷贝的性价比是极低的。
一次处理网络调用的系统I/O的流程：
以上可以发现，传统的Linux系统I/O 操作要进行4次内核空间与应用程序空间的上下文切换，以及4次数据拷贝。
直接内存访问（Direct Memory Access，DMA）是计算机科学中的一种内存访问技术，允许某些电脑内部的硬件子系统独立地读取系统内存，而不需要中央处理器（CPU）的介入。在同等程度的处理器负担下，DMA是一种快速的数据传送方式。这类子系统包括硬盘控制器、显卡、网卡和声卡。
在Linux系统中，当应用程序需要读取文件中的数据时，操作系统先分配一些内存，将数据从存储设备读入到这些内存中，然后再将数据传递应用进程；当需要往文件中写数据时，操作系统先分配内存接收用户数据，然后再将数据从内存写入磁盘。文件cache管理就是对这些由操作系统分配并用开存储文件数据的内存的管理。
在Linux系统中，文件cache分为两个层面，page cache 与 Buffer cache，每个page cache包含若干个buffer cache。操作系统中，磁盘文件都是由一系列的数据块（Block）组成，buffer cache也叫块缓存，是对磁盘一个数据块的缓存，目的是为了在程序多次访问同一个磁盘块时减少访问时间；而文件系统对数据的组织形式为页，page cache为页缓存，是由多个块缓存构成，其对应的缓存数据块在磁盘上不一定是连续的。也就是说buffer cache缓存文件的具体内容--物理磁盘上的磁盘块，加速对磁盘的访问，而page cache缓存文件的逻辑内容，加速对文件内容的访问。
buffer cache的大小一般为1k，page cache在32位系统上一般为4k，在64位系统上一般为8k。磁盘数据块、buffer cache、page cache及文件的关系如下图：
文件cache的目的是加快对数据文件的访问，同时会有一个预读过程。对于每个文件的第一次读请求，系统会读入所请求的页面并读入紧随其后的几个页面；对于第二次读请求，如果所读页面在cache中，则会直接返回，同时又一个异步预读的过程（将读取页面的下几页读入cache中），如果不在cache中，说明读请求不是顺序读，则会从磁盘中读取文件内容并刷新cache。因此在顺序读取情况下，读取数据的性能近乎内存读取。
DMA允许硬件子系统直接将数据从磁盘读取到内核缓冲区，那么在一次数据传输中，磁盘与内核缓冲区，输出设备与内核缓冲区之间的两次数据拷贝就不需要CPU进行调度，CPU只需要进行缓冲区管理、以及创建和处理DMA。而Page Cache/Buffer Cache的预读取机制则加快了数据的访问效率。如下图所示，还是以文件服务器请求为例，此时CPU负责的数据拷贝次数减少了两次，数据传输性能有了较大的提高。
使用DMA的系统I/O操作要进行4次内核空间与应用程序空间的上下文切换，2次CPU数据拷贝及2次DMA数据拷贝。
Mmap内存映射与标准I/O操作的区别在于当应用程序需要访问数据时，不需要进行内核缓冲区到应用程序缓冲区之间的数据拷贝。Mmap使得应用程序和操作系统共享内核缓冲区，应用程序直接对内核缓冲区进行读写操作，不需要进行数据拷贝。Linux系统中通过调用mmap()替代read()操作。
同样以文件服务器获取文件（不加修改）为例，通过mmap操作的一次系统I/O过程如下：
通过以上流程可以看到，数据拷贝从原来的4次变为3次，2次DMA拷贝1次内核空间数据拷贝，CPU只需要调控1次内核空间之间的数据拷贝，CPU花费在数据拷贝上的时间进一步减少（4次上下文切换没有改变）。对于大容量文件读写，采用mmap的方式其读写效率和性能都比较高。（数据页较多，需要多次拷贝）
注：mmap()是让应用程序空间与内核空间共享DMA从磁盘中读取的文件缓冲，也就是应用程序能直接读写这部分PageCache，至于上图中从页缓存到socket缓冲区的数据拷贝只是文件服务器的处理，根据应用程序的不同会有不同的处理，应用程序也可以读取数据后进行修改。重点是虚拟内存映射，内核缓存共享。
djk中nio包下的MappedByteBuffer，官方注释为 A direct byte buffer whose content is a memory-mapped region of a file，即直接字节缓冲区，其内容是文件的内存映射区域。 FileChannel是是nio操作文件的类，其map()方法在在实现类中调用native map0()本地方法，该方法通过mmap()实现，因此是将文件从磁盘读取到内核缓冲区，用户应用程序空间直接操作内核空间共享的缓冲区，Java程序通过MappedByteBuffer的get()方法获取内存数据。
MappedByteBuffer允许Java程序直接从内存访问文件，可以将整个文件或文件的一部分映射到内存中，由操作系统进行相关的请求并将内存中的修改写入到磁盘中。
FileChannel map有三种模式
MappedByteBuffer的应用，以rocketMQ为例（简单介绍）。
procer端发送消息最终会被写入到commitLog文件中，consumer端消费时先从订阅的consumeQueue中读取持久化消息的commitLogOffset、size等内容，随后再根据offset、size从commitLog中读取消息的真正实体内容。其中，commitLog是混合部署的，所有topic下的消息队列共用一个commitLog日志数据文件，consumeQueue类似于索引，同时区分开不同topic下不同MessageQueue的消息。
rocketMQ利用MappedByteBuffer及PageCache加速对持久化文件的读写操作。rocketMQ通过MappedByteBuffer将日志数据文件映射到OS的虚拟内存中（PageCache）,写消息时首先写入PageCache，通过刷盘方式（异步或同步）将消息批量持久化到磁盘；consumer消费消息时，读取consumeQueue是顺序读取的，虽然有多个消费者操作不同的consumeQueue，对混合部署的commitLog的访问时随机的，但整体上是从旧到新的有序读，加上PageCache的预读机制，大部分情况下消息还是从PageCache中读取，不会产生太多的缺页中断（要读取的消息不在pageCache中）而从磁盘中读取。
rocketMQ利用mmap()使程序与内核空间共享内核缓冲区，直接对PageCache中的文件进行读写操作，加速对消息的读写请求，这是其高吞吐量的重要手段。
使用mmap能减少CPU数据拷贝的次数，但也存在一些问题。
从Linux2.1开始，Linux引入sendfile()简化操作。取消read()/write()，mmap()/write()。
调用sendfile的流程如下：
通过sendfile()的I/O进行了2次应用程序空间与内核空间的上下文切换，以及3次数据拷贝，其中2次是DMA拷贝，1次是CPU拷贝。sendfile相比起mmap，数据信息没有进入到应用程序空间，所以能减少2次上下文切换的开销，而数据拷贝次数是一样的。
上述流程也可以看出，sendfile()适合对文件不加修改的I/O操作。
sendfile()只是减少应用程序空间与内核空间的上下文切换，并没有减少CPU数据拷贝的次数，还存在一次内核空间的两个缓冲区的数据拷贝。要实现CPU零数据拷贝，需要引入一些硬件上的支持。在上一小节的sendfile流程中，数据需要从内核缓冲区拷贝到内核空间socket缓冲区，数据都是在内核空间，如果socket缓冲区到网卡的这次DMA数据传输操作能直接读取到内核缓冲区中的数据，那么这一次的CPU数据拷贝也就能避免。要达到这个目的，DMA需要知道存有文件位置和长度信息的缓冲区描述符，即socket缓冲区需要从内核缓冲区接收这部分信息，DMA需要支持数据收集功能。
sendfile()调用后，数据从磁盘文件拷贝到内核缓冲区中，然后将文件位置和长度信息的缓冲区描述符传递到socket缓冲区，此时数据并没有被拷贝。之后网卡子系统根据socket缓冲区中的文件信息利用DMA技术收集拷贝数据。整个过程进行了2次内核空间和应用程序空间的上下文切换，及2次DMA数据拷贝，CPU不需要参与数据拷贝工作，从而实现零拷贝。当然DMA收集拷贝功能需要硬件和驱动程序的支持。
在操作系统中，硬件和软件之间的数据传输可以通过DMA来进行，DMA进行数据传输的过程几乎不需要CPU参与，但是在内核缓冲区（页缓存）与应用程序缓冲区之间的数据拷贝并没有类似于DMA之类的工具可以使用，mmap、sendfile都是为了减少数据在内核空间与应用程序空间传输时的数据拷贝和上下文切换次数，有效地改善数据在两者之间传递的效率。
linux操作系统的零拷贝技术并不单指某一种方式，现有的零拷贝技术种类非常多，在不同的Linux内核版本上有不同的支持。常见的，如果应用程序需要修改数据，则使用mmap()，如果只进行文件数据传输，则可选择sendfile()。
另外，关于零拷贝技术适用于什么场景？在上述的描述中，数据在传递过程中，除了mmap外，应用程序和操作系统几乎是没有改变数据的，mmap的内存映射也是没有改变数据的，也就是说在静态资源的读取场景下，零拷贝更能发挥作用。正如其名，拷贝是在不改变数据的情况下，零是利用手段去减少CPU参与数据拷贝的次数，以释放CPU去进行其他系统调用与计算。