[精彩] inode上限的问题,有默认的值吗?怎么查看呢?

本文讨论了Linux系统中inode的数量及其上限问题。包括如何查看inode信息、inode数量与块大小的关系、创建分区时设置inode数量的方法等。
 原贴:http://www.chinaunix.net/jh/4/280822.html

[精彩] inode上限的问题,有默认的值吗?怎么查看呢?


http://www.chinaunix.net 作者:sunny~tea  发表于:2006-08-17 13:34:18
发表评论】【查看原文】【Linux讨论区】【关闭

[color=darkblue]如何知道一个刚刚装好的机器的每个分区里还有多少个可用的inode?默认的总数是多少呢?如果是和单位block大小成比例关系,那这个比例在装机后又如何调整呢?重新做一遍文件系统吗?是不是在superblock中就可以改呢?望高人指点迷津![/color]



 sunny~tea 回复于:2004-03-15 13:17:13

[color=darkblue]请高手们帮帮忙呀![/color]


 sunny~tea 回复于:2004-03-15 14:44:34

[color=darkblue]没有人遇到过同样问题吗?[/color]


 sunny~tea 回复于:2004-03-15 16:26:51

[color=darkblue]出门靠朋友呀[/color]


 sxsfxx 回复于:2004-03-15 17:02:00

引用:原帖由 "sunny~tea"]
 发表:



找答案靠狗狗,呵呵! :lol:


 sunny~tea 回复于:2004-03-15 18:15:29

[color=darkblue]我就是在狗狗里看英文的眼花了才跑回来偷个懒的,你又把我踹回去[/color]


 弱智 回复于:2004-03-15 21:04:08

这个问题比较有趣,可以参考ext2fs的原理。

http://www.yesky.com/SoftChannel/72350102785622016/20030901/1725271.shtml


 colorbox 回复于:2004-03-15 23:03:55

df -i 查看inode info.


 sakulagi 回复于:2004-03-16 08:27:35

一旦分区创建了以后,inode的最大限制就固定了。


 sunny~tea 回复于:2004-03-17 11:50:05

[color=darkblue]天极的那篇文章我的看上个几天先。分区之后其上限就已固定这一事实的原因是什么呢?我用df -i 看了机器里的信息大概的比例是4G:400,000这个比例数是上限的关键吧,所以在创建分区的时候是不是也有什么参数来设置这一比例呢![/color]


 telecom 回复于:2004-03-17 11:53:42

我见过的最大的inode好像有几十万了,是在一台机器上出现的,导致那个目录无法写入任何的文件


 telecom 回复于:2004-03-17 11:59:27

我见过的最大的inode好像有几十万了,是在一台机器上出现的,导致那个目录无法写入任何的文件


 sakulagi 回复于:2004-03-17 13:15:27

mke2fs -N number-of-inode


 sakulagi 回复于:2004-03-17 13:31:04

dumpe2fs -h  /dev/hdaN  |grep inode

/dev/hdaN是你的linux的各个分区的所在的设备。


 sunny~tea 回复于:2004-03-17 17:48:47

[color=darkblue]mke2fs -N 参数也是根据block和每个inode的字节数之间的比例计算的,所以是不是只有知道了这个比值才能合理设计自己的inode?dumpe2fs中inodesize也挺有意思的嘛不知道有办法改没!谢谢各位高人![/color]


 liuyukoala 回复于:2006-08-17 13:34:18

引用:原帖由 sunny~tea 于 2004-3-15 12:26 发表
[color=darkblue]如何知道一个刚刚装好的机器的每个分区里还有多少个可用的inode?默认的总数是多少呢?如果是和单位block大小成比例关系,那这个比例在装机后又如何调整呢?重新做一遍文件系统吗?是不是在super ... 


df -i看inode数量。默认不知道。和block一点关系都没有




原文链接:http://linux.chinaunix.net/bbs/viewthread.php?tid=280822
转载请注明作者名及原文出处
<think>嗯,用户再次聚焦于struct file和struct inode的区别与联系,看来需要更系统地对比这两个核心结构体。用户提供了两份站内引用[^1][^2],其中[^1]非常清晰地描述了二者的基本差异:file代表动态的打开实例,inode存储静态文件元数据;[^2]则补充了file_operations的操作接口细节。 注意到用户可能是嵌入式开发者或内核学习者,需要理论结合实践的理解。上次回答已概述过二者关系,这次应该深化三点:1)生命周期差异(动态vs静态),2)结构体内存归属(slab分配器vs文件系统),3)典型交互场景(如open时如何关联)。特别要强调"一个inode对应多个file"这个关键点,这在多进程打开同一文件时至关重要。 用户没有询问代码示例,但引用[^2]提到file_operations的函数签名,可以隐含说明:当驱动程序操作inode参数时,实际是在获取文件物理属性;而操作file参数时,则在处理特定进程的上下文(如f_pos)。这能自然引出并发场景下数据一致性的实现机制——例如inode自旋锁如何保护临界区。 考虑到用户连续三次追问内核数据结构,后续问题设计可以更深入:1) 探讨vfs抽象层中super_block的作用,2) 逆向思考为什么file不直接包含inode而用指针关联(内存效率考量),3) 扩展学习ext4文件系统的磁盘inode布局。不过当前回答需保持专注,用表格对比核心差异后,再用文件读写流程示例说明协作关系。 </think>在Linux内核中,`struct file` 和 `struct inode` 是文件系统的核心数据结构,二者协同工作但职责分明。以下是它们的区别与联系详解(基于引用[^1][^2]): --- ### **一、核心区别** | **特性** | **struct file** | **struct inode** | |------------------------|--------------------------------------------|-------------------------------------------| | **本质** | 动态对象 | 静态对象 | | **生命周期** | 文件打开时创建,关闭时销毁 | 文件创建时生成,删除时释放 | | **数量关系** | 同一文件可被多次打开,生成多个`file`实例 | 每个文件唯一对应一个`inode` | | **存储内容** | 文件操作状态(位置指针、打开模式等) | 文件元数据(大小、权限、物理位置等) | | **作用范围** | 进程级别(每个进程独立维护) | 文件系统级别(全局唯一) | | **内核操作接口** | 通过`f_op`链接到`file_operations`函数集[^2] | 作为参数传递给`file_operations`中的函数 | > **典型场景**: > 若进程A和B同时打开`/tmp/test.log`: > - 内核创建 **两个`struct file`**(分别维护A和B的读写位置`f_pos`) > - 但仅有一个共享的 **`struct inode`**(记录文件大小、磁盘块位置等)[^1] --- ### **二、内在联系** 二者的协作通过 **VFS(虚拟文件系统)** 实现: 1. **文件打开流程** ```mermaid graph LR A[open系统调用] --> B[内核创建struct file] B --> C[根据路径查找inode] C --> D[file.f_inode = inode] D --> E[file.f_op = inode关联的操作函数] ``` - `struct file` 通过 `f_inode` 指针关联到对应的 `inode`[^1] - `inode` 决定 `file.f_op` 指向的具体操作函数(如ext4/ntfs的实现) 2. **文件读写流程** 当进程调用 `read()` 时: ```c ssize_t read(struct file *file, char *buf, size_t count, loff_t *pos) { // 通过file->f_inode获取文件物理信息 struct inode *inode = file->f_inode; // 通过file->f_op->read调用驱动函数 return file->f_op->read(file, buf, count, pos); } ``` - `file` 提供操作上下文(如当前偏移量 `f_pos`) - `inode` 提供底层数据定位依据(如磁盘块号)[^2] --- ### **三、典型协作示例** 假设字符设备驱动实现读取操作: ```c static ssize_t mydev_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos) { // 通过filp->f_inode获取设备信息 struct mydev *dev = filp->f_inode->i_private; // 从设备硬件读取数据 copy_to_user(buf, dev->data, len); // 更新文件偏移量(动态状态) *ppos += len; return len; } static struct file_operations fops = { .owner = THIS_MODULE, .read = mydev_read, // 关联到struct file }; // 设备初始化时关联inode与驱动 init_module() { struct inode *inode = ...; inode->i_private = &my_device; // 存储设备私有数据 } ``` > **关键点**: > - `struct file` 处理 **动态状态**(如偏移量更新) > - `struct inode` 存储 **静态信息**(如设备对象指针)[^1][^2] --- ### **四、总结** | **维度** | **struct file** | **struct inode** | |--------------|--------------------------|---------------------------| | **角色** | 文件的“操作句柄” | 文件的“身份证明” | | **变化频率** | 高频变化(每次读写更新) | 低频变化(文件属性修改时)| | **依赖关系** | 依赖inode获取文件信息 | 独立于进程存在 | 二者共同构建了Linux **“文件-操作”分离模型**: $$\text{文件操作} = \underbrace{\text{struct file}}_{\text{动态上下文}} + \underbrace{\text{struct inode}}_{\text{静态元数据}} + \underbrace{\text{file\_operations}}_{\text{操作接口}}$$ 这种设计实现了: 1. 同一文件支持多进程并发访问(各进程维护独立`file`) 2. 文件操作与存储解耦(`inode`可关联不同文件系统) 3. 驱动开发标准化(通过`file_operations`接口)[^1][^2] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值