dentry 와 inode
우선 dentry 데이터 구 조 를 봅 니 다.include / linux / dcache. h 에 있 는 struct dentry
ps: dentry 는 디 렉 터 리 라 는 뜻 이지 만 vfs 에 서 는 디 렉 터 리 와 파일 이 모두 자신의 dentry 를 가지 고 있 습 니 다.(dentry 에 파일 이름 이 저장 되 어 있 습 니 다. 같은 파일 에 별명 이 존재 하 는 것 이 이 구조 입 니 다)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
struct dentry { atomic_td_count; unsignedintd_flags; structinode*d_inode; structdentry*d_parent; structlist_headd_hash; structlist_headd_lru; structlist_headd_child; structlist_headd_subdirs; ， structlist_headd_alias; （ ） intd_mounted; ， structqstrd_name; unsignedlongd_time; /*usedbyd_revalidate*/ structdentry_operations*d_op; structsuper_block*d_sb; vunsignedlongd_vfs_flags; void *d_fsdata; unsignedchard_iname[DNAME_INLINE_LEN]; }; inode 데이터 구 조 를 다시 봅 니 다.include/linux/fs.h
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69
struct inode { /*vfs Linux 465 */ struct hlist_node i_hash; struct list_head i_list; /* backing dev IO list */ struct list_head i_sb_list; struct list_head i_dentry; /* */ unsigned long i_ino; /* */ atomic_t i_count; unsigned int i_nlink; uid_t i_uid; gid_t i_gid; dev_t i_rdev; unsigned int i_blkbits; u64 i_version; loff_t i_size; #ifdef __NEED_I_SIZE_ORDERED seqcount_t i_size_seqcount; #endif struct timespec i_atime; struct timespec i_mtime; struct timespec i_ctime; blkcnt_t i_blocks; unsigned short i_bytes; umode_t i_mode; spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */ struct mutex i_mutex; struct rw_semaphore i_alloc_sem; const struct inode_operations *i_op; /* */ const struct file_operations *i_fop; /* former ->i_op->default_file_ops */ struct super_block *i_sb; struct file_lock *i_flock; struct address_space *i_mapping; struct address_space i_data; #ifdef CONFIG_QUOTA struct dquot *i_dquot[MAXQUOTAS]; #endif struct list_head i_devices; union { struct pipe_inode_info *i_pipe; struct block_device *i_bdev; struct cdev *i_cdev; }; __u32 i_generation; #ifdef CONFIG_FSNOTIFY __u32 i_fsnotify_mask; /* all events this inode cares about */ struct hlist_head i_fsnotify_mark_entries; /* fsnotify mark entries */ #endif #ifdef CONFIG_INOTIFY struct list_head inotify_watches; /* watches on this inode */ struct mutex inotify_mutex; /* protects the watches list */ #endif unsigned long i_state; unsigned long dirtied_when; /* jiffies of first dirtying */ unsigned int i_flags; atomic_t i_writecount; #ifdef CONFIG_SECURITY void *i_security; #endif #ifdef CONFIG_FS_POSIX_ACL struct posix_acl *i_acl; struct posix_acl *i_default_acl; #endif void *i_private; /* fs or device private pointer */ } '파일' 은 일정한 형식 으로 미디어 에 저 장 된 정보 입 니 다. 이 정 보 는 두 가지 측면 을 포함 합 니 다. 하 나 는 저 장 된 데이터 자체 이 고 다른 하 나 는 파일 의 메타 정보 와 데이터 가 차지 하 는 block 의 id 색인 데이터 입 니 다. (이 정 보 는 모두 파일 에 대응 하 는 inode 에 조직 되 어 있 습 니 다)메모리 에 있 는 모든 파일 에는 inode 와 dentry 구조 가 있 습 니 다.dentry 는 파일 이름, 상위 디 렉 터 리, 하위 디 렉 터 리 등 정 보 를 기록 합 니 다. 바로 우리 가 본 (디 렉 터 리 트 리, 파일 트 리) 트 리 구조 입 니 다.inode 는 저장 매체 에 파일 의 위치 와 분 포 를 기록 하고 있 습 니 다. dentry - > dinode 는 대응 하 는 inode 구 조 를 가리킨다.inode 는 물리 적 의미 의 파일 을 대표 합 니 다. inode 를 통 해 하나의 배열 을 얻 을 수 있 습 니 다. 이 배열 은 파일 내용 의 위 치 를 기록 합 니 다. 만약 에 배열 이 (4, 5, 9) 이면 해당 하 는 데 이 터 는 하 드 디스크 의 4, 5, 9 블록 에 있 습 니 다.그 색인 노드 번호 (즉 inode 번호) 는 inode - > ino 이 며, ino 에 따라 하 드 디스크 에 있 는 inode 의 구체 적 인 위 치 를 계산 할 수 있 습 니 다.
dentry 는 논리 적 의미 의 파일 을 묘사 하고 파일 논리 적 속성 을 묘사 하기 때문에 dentry 는 디스크 에 대응 하 는 이미지 가 없습니다.한편, inode 구 조 는 물리 적 의미 의 파일 을 대표 하기 때문에 디스크 에 도 inode 구조 가 있다.
inode 구조 중 하나의 대기 열 identry, 같은 파일 을 대표 하 는 모든 디 렉 터 리 항목 은 d 를 통 해alias 도 메 인 에 해당 하 는 inode 구조 에 걸 려 있 는 identry 대기 열.또는 하 드 링크 가 존재 하기 때문에 같은 파일 은 여러 가지 표현 형식 이 있 을 수 있 습 니 다. 별명 이 될 수 있 지만 모두 같은 파일 에 대응 하고 같은 inode 에 대응 하기 때문에 inode 에 하나의 필드 가 있어 서 이 별명 을 연결 시 키 고 링크 의 형식 을 사용 합 니 다.
프로 세 스 가 파일 을 열 면 하나의 file 구조 가 대응 합 니 다. 같은 프로 세 스 는 같은 파일 을 여러 번 열 어서 여러 개의 다른 file 구 조 를 얻 을 수 있 습 니 다. file 구 조 는 열 린 파일 의 속성, 읽 기 쓰기 오프셋 포인터 등 을 설명 합 니 다.
두 개의 서로 다른 file 은 같은 dentry 구조 에 대응 할 수 있 습 니 다. 프로 세 스 는 한 개의 파일 을 여러 번 열 었 습 니 다. 하나의 dentry 구조 에 대응 합 니 다. dentry 는 디 렉 터 리 항목 과 해당 하 는 파일 의 inode 정 보 를 저장 합 니 다.
미디어 에 서 는 파일 마다 하나의 inode 노드 에 대응 합 니 다. 파일 마다 여러 개의 파일 이름 이 있 습 니 다. 즉, 서로 다른 파일 이름 으로 같은 파일 에 접근 할 수 있 습 니 다. 여러 파일 이름 이 하나의 파일 에 대응 하 는 관 계 는 데이터 구조 에서 dentry 와 inode 가 하나 가 더 많은 관계 입 니 다.inode 에 파일 이름 을 저장 하지 않 고 노드 번호 만 있 습 니 다. 노드 번호 (ino) 를 통 해 데이터 가 미디어 에 있 는 구체 적 인 위 치 를 찾 을 수 있 습 니 다. 즉, 메모리 inode 구조 중의 ino 를 통 해 디스크 의 inode 구 조 를 찾 을 수 있 습 니 다.한편, dentry 는 파일 이름과 대응 하 는 노드 번호 (inode 번호) 를 저장 하면 서로 다른 파일 이름 으로 inode 에 접근 할 수 있 습 니 다.서로 다른 dentry 는 ln 명령 을 통 해 이 루어 집 니 다.
dentry 트 리 는 파일 시스템 디 렉 터 리 구 조 를 묘 사 했 지만 전체 디 렉 터 리 구 조 는 메모리 에 오래 머 물 수 없습니다. 매우 크기 때 문 입 니 다.메모리 가 부족 합 니 다.
초기 상태 에서 시스템 은 루트 디 렉 터 리 를 대표 하 는 dentry 와 가리 키 는 inode 만 있 습 니 다 (루트 파일 시스템 에서 마 운 트 생 성).이 때 파일 을 열 려 면 파일 경로 에 대응 하 는 노드 가 존재 하지 않 습 니 다. 루트 디 렉 터 리 의 dentry 는 필요 한 하위 노드 를 찾 을 수 없습니다.이 때 는 inode - > i 를 통 해op 에서 lookup 방법 은 inode 의 하위 노드 를 찾 고 찾 은 후에 dentry 와 관련 된 것 을 만 듭 니 다.
이 과정 에서 알 수 있다.먼저 inode 가 있 고 dentry 가 있 습 니 다.
생 성 된 dentry 아무 도 사용 하지 않 을 때 방출, dcount 필드 는 dentry 의 인용 수 를 기록 하고 0 으로 인용 하면 dentry 가 풀 립 니 다.이 석방 은 직접 소각 하 는 것 이 아니 라 dentry 를 '최근 최소 사용' 대기 열 에 넣 는 것 입 니 다.대기 열 이 너무 크 고 메모리 가 부족 할 때 dentry 가 풀 립 니 다.이 LRU 대기 열 은 캐 시 풀 과 같 습 니 다. 중 복 된 경로 에 대한 접근 을 가속 화 합 니 다. dentry 가 진정 으로 풀 려 날 때 해당 하 는 inode 는 인용 을 줄 입 니 다. 0 으로 참조 하면 inode 도 풀 립 니 다.
따라서 파일 경 로 를 찾 아야 할 때 세 가지 상황 이 있 습 니 다.
1. dentry 인용 이 0 이상 이면 dentry 트 리 에서 직접 찾 습 니 다.
2. dentry 는 트 리 가 아 닙 니 다. lru 대기 열 에서 찾 습 니 다. LRU 대기 열 에 있 는 dentry 는 흩 어 진 목록 에 흩 어 져 있어 찾기 쉽 습 니 다. 찾 으 면 dentry 트 리 에 다시 추가 합 니 다.
3. 2 도 찾 지 못 하면 inode 를 찾 아 해당 하 는 dentry 를 만 듭 니 다.
각 디 렉 터 리 항목 의 대상 을 다음 과 같은 네 가지 상태 에서 보충 할 수 있 습 니 다.
1: 남 은 상태 이 디 렉 터 리 항목 은 올 바른 정 보 를 포함 하지 않 고 VFS 에 사용 되 지 않 았 다 는 것 이다.
2. 미사 용 상태 해당 대상 의 dcount 계 수 는 0 이지 만 dinode 는 관련 색인 노드 (inode) 를 가리 키 고 있 습 니 다.
3. 사용 중인 상태 해당 대상 의 dcount 계 수 는 0 이 아니 지만 dinode 는 관련 색인 노드 를 가리 키 고 있 습 니 다.
4. 마이너스 상태 디 렉 터 리 항목 과 연 결 된 색인 노드 가 존재 하지 않 습 니 다.
mount 과정:
Liux 는 먼저 디스크 파 티 션 의 슈퍼 블록 을 찾 은 다음 디스크 의 inode table 과 file data 를 분석 합 니 다.자신의 dentry 목록 과 inode 목록 을 만 듭 니 다.VFS 는 Ext 의 방법 에 따라 구 축 된 것 으로 둘 은 매우 비슷 하 다.예 를 들 어 inode 결점.ext_inode 노드 의 일부 구성원 변 수 는 사실 쓸모 가 없습니다. 예 를 들 어 인용 계수 등 은 vfs - inode 와 일치 하기 위해 서 입 니 다. 이렇게 ext 를 사용 합 니 다.inode 구축 vfsinode 는 하나의 할당 이 필요 없 이 한 번 만 복사 할 수 있 습 니 다.
따라서 ext 형식 이 아 닌 파일 시스템 은 mount 과정 이 느 릴 수 있 습 니 다.
루트 디 렉 터 리 는 dentry 구 조 를 가지 고 있 으 며, 루트 디 렉 터 리 의 파일 과 디 렉 터 리 는 모두 이 dentry 에 연결 되 어 있 습 니 다.같은 이치 로 2 급 디 렉 터 리 에 있 는 파일 과 디 렉 터 리 가 2 급 디 렉 터 리 에 연결 되 어 있 습 니 다. 이렇게 한 층 한 층 씩 dentry 트 리 가 형성 되 었 습 니 다.트 리 꼭대기 에서 파일 시스템 전 체 를 옮 겨 다 닐 수 있 습 니 다.
dentry 에 대한 검색 을 가속 화하 기 위해 커 널 은 hash 표를 사용 하여 dentry 를 캐 시 합 니 다. dentry cache 라 고 합 니 다. dentry 는 일반적으로 dentry cache 에서 찾 습 니 다 (이에 대응 하 는 inode 는 커 널 공간 에서 hash 표를 사용 하여 캐 시 합 니 다. 파일 의 내용 은 페이지 고속 캐 시 page cache 를 사용 하여 캐 시 합 니 다. address space 와 기본 트 리 를 사용 하여 page cache 의 페이지 를 관리 합 니 다).
dentry 구조 에 dsubdirs 멤버 와 dchild 멤버.d_subdirs 는 하위 항목 의 체인 헤더 입 니 다. 모든 하위 항목 은 이 링크 에 연결 해 야 합 니 다. dchild 는 자신의 체인 헤더 입 니 다. 부모 dentry 에 연결 해 야 하 는 dsubdirs 멤버.
d_parent 는 포인터 로 부모 dentry 구 조 를 가리킨다.
d_hash 는 dentry cache 에 연 결 된 hash 링크 입 니 다.
d_디 렉 터 리 나 파일 의 이름 을 저장 합 니 다.파일 을 열 때 이 구성원 과 사용자 가 입력 한 이름 에 따라 목 표를 찾 습 니 다.
d_mounted 는 dentry 가 마 운 트 지점 인지 아 닌 지 를 표시 합 니 다.그렇다면, 멤버 는 0 이 아니다.
dentry 의 hash 포 지 셔 닝, d 통과hash () 함 수 는 부모 디 렉 터 리 dentry 의 주소 와 찾 을 파일 이름 의 hash 값 을 결합 하여 hash 값 을 다시 계산 하고 그 위치 에 따라 dentryhashtable 해시 표 에서 (즉, 특정한 표 머리 를 찾 고 검색 범 위 를 좁 히 는 것) 이 표 는 dentry 캐 시 일부분 입 니 다. 그 다음 에 이 링크 를 스 캔 하여 대상 dentry 를 찾 습 니 다. 찾 지 못 하면 reallookup () 함수 가 디스크 에서 찾 습 니 다.
디 렉 터 리 항목 대상 은 dentry 에 저 장 됩 니 다.cache 의 slab 캐 시 에 있 습 니 다.그러므로 디 렉 터 리 항목 의 생 성과 삭 제 는 kmem 을 통 해cache_alloc () 와 kmemcache_free () 로 이 루어 졌 다.디 렉 터 리 항목 의 고속 캐 시 는 두 가지 유형의 데이터 구조 로 구성 되 어 있 습 니 다.
1. 사용 중이 거나 사용 하지 않 거나 마이너스 상태 에 있 는 디 렉 터 리 항목 대상 의 집합.
2. 흩 어 진 목록주어진 파일 이름과 디 렉 터 리 이름 에 대응 하 는 디 렉 터 리 항목 의 대상 을 hash 에서 빠르게 찾 을 수 있 습 니 다.산열 표 는 dentryhashtable 배열 구현.배열 의 모든 요 소 는 링크 를 가리 키 는 지침 이다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Linux에서 하드 드라이브 파티션이나 파일 시스템의 UUID를 가져오는 7가지 방법Linux 시스템 관리자로서 파티션의 UUID나 파일 시스템의 UUID를 보는 방법을 알아야 합니다.현재 대부분의 Linux 시스템에서 UUID를 사용하여 파티션을 마운트하기 때문입니다.당신은 /etc/fstab 파...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
