接上文:

crash> struct -xo dentry.d_inode ffff8818118002c0
struct dentry {
[ffff8818118002d0] struct inode *d_inode;
}
crash> struct dentry.d_inode ffff8818118002c0
d_inode = 0xffff880c11402cf8
crash> struct inode 0xffff880c11402cf8
struct inode {
i_hash = {
next = 0x0,
pprev = 0xffffc900093d9118
},
i_list = {
next = 0xffff880c11401ae8,
prev = 0xffff880c11b9bda8
},
i_sb_list = {
next = 0xffff880c1188ccd0,------------inode的i_sb_list串起来,形成一个双向循环链表,其链表头可以认为是该inode对应的super_block的s_inodes成员的地址
prev = 0xffff880c11402a98
},
i_dentry = {
next = 0xffff881811800330,
prev = 0xffff881811800330
},
i_ino = ,
i_count = {
counter =
},
i_nlink = ,
i_uid = ,
i_gid = ,
i_rdev = ,
i_version = ,
i_size = ,
i_atime = {
tv_sec = ,
tv_nsec =
},
i_mtime = {
tv_sec = ,
tv_nsec =
},
i_ctime = {
tv_sec = ,
tv_nsec =
},
i_blocks = ,
i_blkbits = ,
i_bytes = ,
i_mode = ,
i_lock = {
raw_lock = {
slock =
}
},
i_mutex = {
count = {
counter =
},
wait_lock = {
raw_lock = {
slock =
}
},
wait_list = {
next = 0xffff880c11402db8,
prev = 0xffff880c11402db8
},
owner = 0x0
},
i_alloc_sem = {
count = ,
wait_lock = {
raw_lock = {
slock =
}
},
wait_list = {
next = 0xffff880c11402de0,
prev = 0xffff880c11402de0
}
},
i_op = 0xffffffff8161fb40 <proc_reg_file_ops+>,
i_fop = 0xffffffff8161fc00 <proc_root_inode_operations+>,
i_sb = 0xffff880c1188cc00,
i_flock = 0x0,
i_mapping = 0xffff880c11402e18,
i_data = {
host = 0xffff880c11402cf8,-----------------------address_space的host是指向inode,而inode的i_data是指向对应的address_space,两者就串起来了。
page_tree = {--------------------radix树,主要管理page的
height = ,
gfp_mask = ,
rnode = 0x0
},
tree_lock = {-----------------树锁
raw_lock = {
slock =
}
},
i_mmap_writable = ,
i_mmap = {
prio_tree_node = 0x0,
index_bits = ,
raw =
},
i_mmap_nonlinear = {
next = 0xffff880c11402e48,
prev = 0xffff880c11402e48
},
i_mmap_lock = {
raw_lock = {
slock =
}
},
truncate_count = ,
nrpages = ,
writeback_index = ,
a_ops = 0xffffffff81fcfde0 <empty_aops.>,
flags = ,
backing_dev_info = 0xffffffff81abfb80 <default_backing_dev_info>,
private_lock = {
raw_lock = {
slock =
}
},
private_list = {
next = 0xffff880c11402e90,
prev = 0xffff880c11402e90
},
assoc_mapping = 0x0
},
i_dquot = {0x0, 0x0},
i_devices = {
next = 0xffff880c11402eb8,
prev = 0xffff880c11402eb8
},
{---------------------------这个是inode的类型描述,一个inode要么是字符设备,要么是块设备,要么是pipe设备,要么都不是
i_pipe = 0x0,
i_bdev = 0x0,
i_cdev = 0x0
},
i_generation = ,
i_fsnotify_mask = ,
i_fsnotify_mark_entries = {
first = 0x0
},
inotify_watches = {
next = 0xffff880c11402ee0,
prev = 0xffff880c11402ee0
},
inotify_mutex = {
count = {
counter =
},
wait_lock = {
raw_lock = {
slock =
}
},
wait_list = {
next = 0xffff880c11402ef8,
prev = 0xffff880c11402ef8
},
owner = 0x0
},
i_state = ,
dirtied_when = ,
i_flags = ,
i_writecount = {
counter =
},
i_security = 0x0,
i_acl = 0xffffffffffffffff,
i_default_acl = 0xffffffffffffffff,
i_private = 0x0
}

每个inode对于所属的文件系统来说,是唯一的。比如有两个硬盘,都是xfs分别挂载到两个挂载点,那么对应的这个文件系统里,inode的内存地址也是唯一的,但是可以和其他文件系统中的i_ino成员可能会相同。

inode和对应的super_block 怎么对应起来呢,inode的i_sb_list串起来,形成一个双向循环链表,其链表头可以认为是该inode对应的super_block的s_inodes成员的地址,我们验证一下:

crash> struct inode 0xffff880c11402cf8
struct inode {
i_hash = {
next = 0x0,
pprev = 0xffffc900093d9118
},
i_list = {
next = 0xffff880c11401ae8,
prev = 0xffff880c11b9bda8
},
i_sb_list = {
next = 0xffff880c1188ccd0,--------对应的地址是ccd0
prev = 0xffff880c11402a98
},

可以看到,该inode对应的i_sb_list是ccd0,而该inode归属的super_block是0xffff880c1188cc00,

crash> struct -xo super_block.s_inodes
struct super_block {
[0xd0] struct list_head s_inodes;
}
crash> px 0xffff880c1188cc00+0xd0
$ = 0xffff880c1188ccd0

两者对得上,是不是很面熟,前面我们看dentry的时候,所有子dentry的d_child成员就形成双向循环链表,嵌入到父dentry的d_subdirs中,内核中类似手法很多。

前面文章描述过dentry,但是看inode中,有一个dentry链表,这个是为啥?难道两者不是一一对应关系么?

事实上,两者真不是一一对应,一个inode可能有多个dentry:

crash> struct inode 0xffff880c11402cf8
struct inode {
i_hash = {
next = 0x0,
pprev = 0xffffc900093d9118
},
i_list = {
next = 0xffff880c11401ae8,
prev = 0xffff880c11b9bda8
},
i_sb_list = {
next = 0xffff880c1188ccd0,
prev = 0xffff880c11402a98
},
i_dentry = {
next = 0xffff881811800330,
prev = 0xffff881811800330
}, crash> struct -xo dentry.d_alias
struct dentry {
[0x70] struct list_head d_alias;
}
crash> px 0xffff881811800330-0x70
$ = 0xffff8818118002c0 crash> struct dentry 0xffff8818118002c0
struct dentry {
d_count = {
counter =
},
d_flags = ,
d_lock = {
raw_lock = {
slock =
}
},
d_mounted = ,
d_inode = 0xffff880c11402cf8,
d_hash = {
next = 0x0,
pprev = 0x0
},
d_parent = 0xffff8818118002c0,
d_name = {
hash = ,
len = ,
name = 0xffff881811800360 "/"
},

对于本例中的根目录来说,一个inode只有一个dentry,但是对于硬链接来说,则肯定有多个dentry,所以inode和dentry是1对多的关系。

又同时可以看到,dentry中的d_alias串起来一个双向循环链表,而这个双向循环链表遍历的时候,可以认为这些dentry对应的inode的 i_dentry 是这个双向循环链表的头。

其实inode还有个很关键常用的成员,就是i_list,根据不同的inode状态,会放入不同的list,但是由于这个成员在3.10内核中已经被i_lru和i_wb_list 来代替了,这个两个成员都会嵌入到

该inode所属的superblock的s_inode_lru 以及i_wb_list中。所以就不放在本文中分析了。

最后,通过files -d dentry的地址 ,可以显示对应的inode和superblock,-p的话,还可以展示在pagecache中的page:

crash> files -d ffff8857a2440b40
DENTRY INODE SUPERBLK TYPE PATH
ffff8857a2440b40 ffff88535be752b0 ffff88013d3a8800 REG /mnt/ZMSS/ZMSSThreadMonitor.log
crash> files -p ffff88535be752b0
INODE NRPAGES
ffff88535be752b0 PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0121bbd840 486ef61000 ffff88535be75400 6fffff000c0038 uptodate,dirty,lru,reclaim,swapbacked

linux 2.6.32文件系统的inode的更多相关文章

  1. linux 2.6.32文件系统的dentry父子关系

    我们知道,linux文件系统,inode和dentry是有对应关系的,dentry是文件名或者目录的一个管理结构,2.6内核中: struct dentry { atomic_t d_count; u ...

  2. linux 2.6.32文件系统 fd与file*之间的关系

    给定如下一定情况: crash> files PID: TASK: ffff8817facd2100 CPU: COMMAND: "slabtop" ROOT: / CWD: ...

  3. Linux文件系统(inode、block……)

    内容源于<鸟哥的Linux私房菜> 认识 EXT2 文件系统 文件系统的特殊观察与操作 文件系统 superblock,inode,block superblock,inode,block ...

  4. Linux文件系统与inode、Block笔记

    Linux文件系统与inode.Block笔记 在Linux下一切都是文件,无论是设备还是接口,亦或是网卡等均被抽象成了文件,并且有相关的内核代码进行调度.然而,在一切都是文件的前提下,最需要进行探讨 ...

  5. 【转】linux IO子系统和文件系统读写流程

    原文地址:linux IO子系统和文件系统读写流程 我们含有分析的,是基于2.6.32及其后的内核. 我们在linux上总是要保存数据,数据要么保存在文件系统里(如ext3),要么就保存在裸设备里.我 ...

  6. 深入理解linux系统下proc文件系统内容

    深入理解linux系统下proc文件系统内容 内容摘要:Linux系统上的/proc目录是一种文件系统,即proc文件系统. Linux系统上的/proc目录是一种文件系统,即proc文件系统.与其它 ...

  7. 一起来学linux:磁盘与文件系统:

    对于文件系统来说,windows上最长用的就是FAT32和NTFS.在Linux上时候用的是Ext2.在linux中,文件权限与文件属性这两部分会被存储在不同的块,权限与权限放置到inode中,实际数 ...

  8. linux操作系统故障处理-ext4文件系统超级块损坏修复

    linux操作系统故障处理-ext4文件系统超级块损坏修复   背景 前天外面出差大数据测试环境平台有7台服务器挂了,同事重启好了五台服务器,但是还有两台服务器启动不起来,第二天回来后我和同事再次去机 ...

  9. linux常用命令之文件系统

    df df - report file system disk space usage 查看文件系统的使用清空 用法 df [-hi] [path] 选项 -h human readable ,以人类 ...

随机推荐

  1. asp.net mvc 5 单元测试小例子

    using System.Collections.Generic; using System.Linq; using Microsoft.VisualStudio.TestTools.UnitTest ...

  2. MySQL 之 MySQL数据库的优化

    服务器物理硬件的优化 在挑选硬件服务器时,我们应该从下面几个方面着重对MySQL服务器的硬件配置进行优化,也就是说将项目中的资金着重投入到如下几处: 1.磁盘寻道能力(磁盘I/O),我们现在用的都是S ...

  3. Splunk和ElasticSearch深度对比解析(转)

    转载自:http://www.sohu.com/a/154105465_354963 随着Splunk越来越被大家熟知和认可,现在市面上也不断涌各种同类产品,作为大数据搜索界的翘楚Splunk和Ela ...

  4. js常用内置对象

    数组Array 1创建方式 var colors = ['red','color','yellow']; var colors2 = new Array(); 2数组的赋值 var arr = []; ...

  5. switch的穿透,是参数里包含case内容就执行。

    package rom; import java.lang.*; /* * switch的穿透,是参数里包含case内容就执行. */ public class Xamle_5 { public st ...

  6. [Lua]弱引用table

    参考链接: http://www.benmutou.com/archives/1808 一.强引用table lua中的table是引用类型,更准确地说,是强引用类型.如下第二段代码,在内存中有一个{ ...

  7. fabric Node SDK进行连接

    yum install gcc-c++ npm install --unsafe-perm --registry=https://registry.npm.taobao.org chmod -R

  8. Linux网络管理-相关笔记【自用】

    ISO/OSI七层模型应用层            APDU 应用层协议数据单元   越靠近用户表示层            PPDU 表示层协议数据单元会话层            SPDU 会话协 ...

  9. 解决Cell重用问题

    在显示的过程中,出现了内容重叠的问题,其实就是UITableViewCell重用机制的问题. 解决方法一:对在cell中添加的控件设置tag的方法 在cell的contentView上需要添加控件,那 ...

  10. 2.HTML文件中<!DOCTYPE html>的作用

    <!DOCTYPE> 声明位于文档中的最前面的位置,处于 <html> 标签之前.此标签可告知浏 览器文档使用哪种 HTML 或 XHTML 规范.(重点:告诉浏览器按照何种规 ...