欢迎来到皮皮网官网
1.usbstor.sys安装驱动程序的磁盘程序磁盘程序小型批处理文件
2.[转载] 细说jbd （journal-block-device）& 源码分析
3.linux设备驱动程序——设备树(0)-dtb格式
4.xfs文件系统：layout与架构、源码分析
usbstor.sys安装驱动程序的小型批处理文件
以下是一个安装驱动程序的小型批处理文件，可参考以方便下次自行编写。源码源码
请确保您的分析方法分析方法系统为Windows XP，安装在C盘，磁盘程序磁盘程序MP4与PC连接无误。驱动驱动最新捕鱼源码运营版本文件仅用于测试。源码源码
请阅读并同意以下条款，分析方法分析方法否则请停止操作。磁盘程序磁盘程序
本软件版权所有，驱动驱动任何未经许可的源码源码转载或使用源代码均视为侵权行为。
确认当前环境满足条件后，分析方法分析方法继续执行。磁盘程序磁盘程序
正在检查安装包完整性，驱动驱动可能需要几秒钟时间。源码源码
如果发现安装出现问题，请停止执行。
文件检查无误，开始安装。
启用临时设置，复制文件。设备信息文件、CAN源码详解驱动程序信息说明文件、USB端口—磁盘驱动器主文件。
复制完成，所有文件安装成功。
复原临时设置，安装完成。
现在可以拔除并再次接入设备测试是否能够正常使用，如有问题，请联系我们。
请确认当前环境满足安装条件，执行安装程序。
如果安装过程中出现错误，请停止执行并尝试再次安装。
所有文件安装成功，设置复原完成，安装完成。
现在可以拔除并再次接入设备进行测试。如无法正常使用或在安装过程中遇到问题，请联系我们。
[转载] 细说jbd （journal-block-device）& 源码分析
jbd 要解决什么问题
文件系统某些操作抽象成原子操作
若干个原子操作组成一个事务
在磁盘上单独划分一个日志空间
将内存事务的数据写到日志中
从日志恢复数据
概念介绍
buffer_head 元数据块
handle transaction journal commit checkpoint revoke recover kjournald
数据结构介绍
handle_t 表示一个原子操作
transaction_t 表示一个事务
journal_t journal_superblock_t journal_head journal_head_t
三种日志模式
jbd基本操作
journal_start journal_stop journal_get_create_access journal_get_write_access journal_get_undo_access
journal_dirty_data journal_dirty_metadata journal_forget journal_revoke journal_extend
元数据缓冲区处理流程
数据缓冲区处理流程
提交事务kjournald----- 时刻准备着
fs/jbd/journal.c
提交事务
journal_commit_transaction __journal_clean_checkpoint_list journal_submit_data_buffers
fs/jdb/commit.c
journal_write_revoke_records journal_write_metadata_buffer journal_write_commit_record
数据块缓冲区状态转移图
元数据块缓冲区状态转移图
日志恢复
准备工作
journal_recover 函数
恢复步骤1： PASS_SCAN
恢复步骤2：PASS_REVOKE
恢复步骤3：PASS_REPLAY
恢复后的设置工作
linux设备驱动程序——设备树(0)-dtb格式
设备树的一般操作方式是：开发人员根据开发需求编写dts文件，然后使用dtc将dts编译成dtb文件。go netpool源码
dts文件是文本格式的文件，而dtb是二进制文件，在linux启动时被加载到内存中，接下来我们需要来分析设备树dtb文件的格式。
为什么要了解设备树dtb文件的格式
dtb作为二进制文件被加载到内存中，然后由内核读取并进行解析，如果对dtb文件的格式不了解，那么在看设备树解析相关的内核代码时将会寸步难行，而阅读源代码才是了解设备树最好的方式，所以，如果需要更透彻的了解设备树解析的细节，第一步就是需要了解设备树的格式。
dtb格式总览
dtb的格式是这样的：
dtb header
但凡涉及到数据的记录，就一定会有一个总的描述部分，就像磁盘的超级块，书的目录，dtb当然也不例外，这个描述头部就是dtb的header部分，通过这个header部分，用户可以快速地了解到整个dtb的大致信息。
header可以用这么一个结构体来描述：
magic
设备树的swiper编程源码魔数，魔数其实就是一个用于识别的数字，表示设备树的开始，linux dtb的魔数为 0xddfeed.
totalsize
这个设备树的size，也可以理解为所占用的实际内存空间。
off_dt_struct
offset to dt_struct，表示整个dtb中structure部分所在内存相对头部的偏移地址
off_dt_strings
offset to dt_string，表示整个dtb中string部分所在内存相对头部的偏移地址
off_mem_rsvmap
offset to memory reserve map，dtb中memory reserve map所在内存相对头部的偏移地址，
version
设备树的版本，截至目前的最新版本为.
last_comp_version
最新的兼容版本
boot_cpuid_phys
这部分仅在版本2中存在，后续版本不再使用。
size_dt_strings
表示整个dtb中string部分的大小
size_dt_struct
表示整个dtb中struct部分的大小
alignment gap
中间的alignment gap部分表示对齐间隙，它并非是必须的，它是否被提供以及大小由具体的平台对数据对齐和的要求以及数据是否已经对齐来决定。
memory reserve map
memory reserve map：描述保留的内存部分，这个map的数据结构是这样的：
这部分存储了此结构的列表，整个部分的结尾由一个数据为0的结构来表示(即physical_address和size都为0，总共字节)。
这一部分的数据并非是节点中的memory子节点，而是在设备开始之前(也就是第一个花括号之前)定义的,例如：
这一部分的作用是告诉内核哪一些内存空间需要被保留而不应该被系统覆盖使用，因为在内核启动时常常需要动态申请大量的同城派对源码内存空间，只有提前进行注册，用户需要使用的内存才不会被系统征用而造成数据覆盖。
值得一提的是，对于设备树而言，即使不指定保留内存，系统也会默认为设备树保留相应的内存空间。
同时，这一部分需要位(8字节)对齐。
device-tree structure
device-tree structure：每个节点都会被描述为一个struct，节点之间可以嵌套，因此也会有嵌套的struct。
structure的的结构是这样的：
device-tree strings
device-tree strings：在dtb中有大量的重复字符串，比如"model","compatile"等等，为了节省空间，将这些字符串统一放在某个地址，需要使用的时候直接使用索引来查看。
需要注意的是，属性部分格式为key = value，key部分被放置在strings部分，而value部分的字符串并不会放在这一部分，而是直接放在structure中。
dtb文件解析示例
光说不练假把式，下面我就使用一个简单的示例来剖析dtb的文件格式。
下述示例仅仅是一个演示demo，不针对任何平台，为了演示方便，编写了一个非常简单的dts文件。 /dts-v1/; / {
编译当前dts文件，获取对应的dtb文件。
鉴于dtb文件为二进制文件，普通编辑器打开显示乱码，我们使用ultraEdit查看，它将数据以进制形式显示：
整个dtb文件还是比较简单的，图中的红色框出的部分为header部分的数据，可以看到：
整个头部为字节，进制为0x，从头部信息中off_mem_rsvmap部分可以得到，reserve memory起始地址为0x，上文中提到，这一部分使用一个字节的struct来描述，以一个全为0的struct结尾。
后字节全为0，可以看出，这里并没有设置reserve memory。
structure 部分
上文回顾：每一个属性都是以 key = value的形式来描述，value部分可选。
偏移地址来到0x(0x+0x),接下来8个字节为，根据上述structure中的描述，这是OF_DT_PROP，即标示属性的开始。
接下来4字节为，表明该属性的value部分size为字节。
接下来4字节是当前属性的key在string 部分的偏移地址，这里是，由头部信息中off_dt_strings可以得到，string部分的开始为，偏移地址为0，所以对应字符串为"compatible".
之后就是value部分，这部分的数据是字符串，可以直接从右侧栏看出，总共字节的字符串"hd,test_dts", "hd,test_xxx",因为字符串之间以0结尾，所以程序可以识别出这是两个字符串。
可以看出，到这里，compatible = "hd,test_dts", "hd,test_xxx";这个属性就被描述完了，对于属性的描述还是非常简单的。
按照固有的规律，接下来就是对#address-cells = <0x1>的解析，然后是#size-cells = <0x1>...
然后就是递归的子节点chosen，memory@等等都是按照上文中提到的structure解析规则来进行解析，最后以结尾。
与根节点不同的是，子节点有一个unit name，即chosen，memory@这些名称，并非节点中的.name属性。
而整个结构的结束由来描述。
一般而言，在位系统中，dtc在编译dts文件时会自动考虑对齐问题，所以对于设备树的对齐字节，我们只需要有所了解即可，并不会常接触到。
好了，关于linux设备树dtb文件格式的讨论就到此为止啦。
xfs文件系统：layout与架构、源码分析
本文由腾讯工程师aurelian撰写，深入解析Linux内核中xfs文件系统的layout与架构，结合源码剖析其工作原理。首先，xfs的layout包括超级块、AGF管理（空闲空间追踪）、AGI管理（inode管理）、AGFL（空闲链表）以及B+树结构等组成部分，每个部分都有其特定功能，如超级块用于存储关键信息，B+树用于快速查找空间。
在文件操作方面，xfs支持iops、fops和aops三个操作集，分别负责inode元数据、内存级读写和磁盘级读写。创建文件时，会检查quota并预留空间，通过一系列函数如xfs_trans_reserve_quota和xfs_dir_ialloc进行操作。分配inode时，会依据agi信息和ag的空闲情况动态分配，并通过xfs_iget确保inode在核心内存中可用。
磁盘级inode分配涉及agi信息的获取和B+树的查找，xfs_ialloc_ag_alloc会根据空闲inode情况完成连续或非连续的分配。写操作涉及内存和磁盘级别，buffer io通过page cache管理，直接io和DAX write则有特定的处理方式。xfs的映射关系和data区域树管理对于高效读写至关重要。
工具方面，mkfs.xfs用于格式化，xfs_fsr、xfs_bmap、xfs_info等用于维护和监控文件系统，xfs_admin和xfs_copy用于系统参数调整和数据复制，xfs_db则是用于调试的工具。希望本文能帮助读者理解xfs的复杂性，如需了解更多详情，可关注鹅厂架构师公众号。
