2022/06/04 스터디 4주차 사전정리 & 질문

파일시스템 일반

 

 가상 메모리 관리 기법은 주 기억 장치로 불리는 RAM과 CPU를 관리하는 기법이었고 파일 시스템은 보조 기억 장치인 하드 디스크 등에 적재된 데이터를 관리하는 기법이다. 그 둘은 휘발성 여부, 접근 단위 등 매우 다양한 차이점을 보이기 때문에 소프트웨어 측면에서도 큰 차이점을 가진다. 그럼에도 불구하고 기억 장치를 다룬다는 점에서는 공통적인 면을 보이기도 하는데, 가장 큰 차이점은 뭘까? 파일 시스템은 ‘이름'이라는 특성을 데이터에 부여해 관리하는 점이 가장 큰 차이점이라 말할 수 있다.

 

 그렇다면 이런 파일 시스템 안에는 어떤 데이터가 들어있을까? 파일시스템 안에는 메타 데이터와 사용자 데이터가 들어있다. 메타 데이터는 파일시스템 내에서 ‘아이노드'라고 불리는 파일의 속성 정보를 뜻하며 사용자 데이터는 실제 사용자가 기록하려 했던 내용을 뜻한다.

디스크 구조와 블록 관리 기법

 

 리눅스가 보조 기억 장치를 어떻게 관리하는지 알아보기 위해 하드 디스크가 어떻게 생겼는지 살펴보는 것도 도움이 된다. 아래의 그림을 보면서 이해해보자.

 

하드 디스크의 구조

 

 디스크를 가로로 나눴을 때 같은 범위에 속하는 곳을 트랙이라고 부르고 세로로 나눴을 때 속하는 같은 범위는 섹터라고 부른다. 데이터를 읽을 때는 하드 디스크 암이 정확한 위치를 가리키고 있어야 하는데 그 부분에 있어서 섹터와 트랙은 중요한 기본 단위가 된다. 참고로 각 섹터의 크기는 512byte이다. 탐색 시간, 회전 지연 시간, 데이터 전송 시간에 대한 내용은 링크에 설명이 되어있다.

 

 

 

 하지만 리눅스는 하드 디스크를 물리적인 모양 그대로 받아들이는 게 아닌 논리적인 구조로 바꿔서 사용한다. 위 그림에 나와있듯이 기억 장치를 디스크 블록들로 나눠서 관리하는데 디스크 블록들을 주 기억 장치로 불러와서 사용하는 것이기 때문에 당연히 각 블록의 크기도 4KB이다. 디스크의 I/O 병목 현상때문에 디스크 블록의 크기를 늘릴 수도 있지만 속도를 얻는 대신 공간 효율성 측면에서 떨어지게 된다고 한다.

 

 데이터를 할당할 때에는 두 가지 방법이 있다. 연속 할당과 불연속 할당. 연속 할당은 탐색 시간(디스크 실린더에 헤드를 놓는 시간)을 줄여주기 때문에 속도 면에서는 큰 이점이 있다. 하지만 데이터의 양이 추가가 되고 연속되는 디스크 블록에 남는 공간이 없다면 기존 데이터를 충분한 연속된 디스크 블록이 있는 곳으로 옮겨야 하기 때문에 큰 비용을 지불해야 한다. 반면에 불연속 할당은 데이터 사이즈의 변화 면에서는 자유롭지만 각 데이터 블록은 다음 데이터 블록에 대한 지도를 갖고 있어야 한다. 이를 위해 고안된 기법이 블록체인 기법, 인덱스 블록 기법, FAT(File Allocation Table) 기법 등이 있다.

 

 

 

 블록 체인 기법은 우리에게 친숙한 linked list와 비슷하다. 각 디스크 블록은 다음 디스크 블록의 위치를 담고 있는데 만약 디스크 블록 하나가 유실되면 그 다음 데이터를 가리키는 포인터가 사라지기 때문에 데이터 전체가 유실되게 되는 단점이 있다.

 

 

 인덱스 블록 할당 기법은 데이터 블록을 하나 지정해 데이터 블록에 대한 인덱스 값을 저장하는 기법을 말한다. 이는 우리가 살펴볼 리눅스 파일 시스템인 ext2, ext3, ext4에서 사용하는 기법이며 만약 인덱스 테이블을 담은 데이터 블록이 사라진다면 전체 데이터가 유실된다는 단점이 있다.

 

 

 인덱스 블록 기법이 데이터마다 블록을 할당해 인덱스 테이블을 저장하는 형식이었다면 FAT 할당 기법은 전역 변수처럼 모든 데이터의 순서를 담고 있는 테이블을 하나 생성한다. 이는 윈도우에서 사용하고 있는 파일시스템 기법이다. 테이블이 유실되면 시스템 상 모든 데이터가 유실된다는 단점이 있다. 하지만 그를 극복하기 위해 FAT 파일 시스템은 이 테이블을 중복하여 저장 및 관리한다.

 

FAT 파일 시스템

 

 대표적으로 FAT 파일 시스템에는 어떤 메타 데이터가 존재하는지 알아 보자. FAT 파일 시스템에서 메타데이터는 FAT 테이블, 디렉토리 엔트리(dentry), 그리고 수퍼 블록이 존재한다. 파일 시스템에선 파일을 생성할 때 디렉터리 엔트리를 하나씩 갖는다. 디렉터리 엔트리는 주요한 두 가지의 장점을 갖는다고 말할 수 있다. 첫번째는, 이름을 사용해서 사용자가 데이터를 쉽게 찾을 수 있도록 도와준다. 두번째 장점은 계층 구조를 사용하여 파일의 위치를 효율적으로 기록한다. 예를 들어, /home/name/README’라는 파일을 찾고 싶으면 제일 먼저 ‘/’의 디렉토리 엔트리를 찾는다(파일시스템은 루트 디렉토리 엔트리를 위한 데이터 블록을 따로 갖고 있다. 이를 슈퍼 블록이라고 부른다). 그리고 마치 트리 구조처럼 루트 디렉터리 안에 속해있는 모든 디렉터리를 검토한 후 사용자가 원하는 파일을 찾는다.

 

 

inode 구조

 

 파일시스템에는 아이노드(inode)라는 메타 데이터가 있다. 이는 각 파일에 대한 정보를 담고 있기 때문에 아이노드는 파일마다 존재한다. 아이노드가 어떤 정보를 담고 있는지 알고 싶다면 리눅스에서 ‘stat 파일명' 명령어를 치면 알게 될 것이다. 직관적이고 우리에게 친숙한 정보들이다. 그렇다면 이 아이노드 메타데이터는 파일시스템에서 어떤 필드들을 가질까? 

 

 

 중요한 필드만 몇 가지 살펴 보자면 i_blocks는 파일이 몇 개의 데이터 블록을 사용하고 있는지 나타내며, i_mode는 파일의 속성 및 접근 제어 정보를 갖고 있다. ext 계열 파일시스템의 아이노드에는 direct block과 indirect block이 있는데, 각 블록은 파일이 사용하고 있는 데이터 블록을 가리키고 있다. 하지만 direct block은 데이터 블록에 대한 직접적인 포인터를 갖고있는 반면에, indirect blocks는 또 다른 인덱스 블록을 담고 있는 블록에 대한 포인터를 제공한다(페이징 기법을 생각하시면 이해하시기 쉬울 거예요). 실제로 삼단 인덱싱 테이블 블록 기법을 사용하면 파일은 최대 4TB까지 가질 수 있다고 한다.

 

 전에 디렉터리 엔트리는 파일의 이름과 파일을 매칭해주는 역할을 한다고 서술했는데 이는 ext2 파일시스템의 디렉터리 엔트리 구조체를 보면 알 수 있다. 보다시피 디렉터리 엔트리는 아이노드 번호와 파일의 이름을 담는 필드가 각각 존재하는 것을 확인할 수 있다.

 

 

 

 

Ext2 파일 시스템

 

 컴퓨터를 듀얼 부팅 시키거나 디스크를 초기화할 때 파티션이라는 단어를 한 번씩은 들어본 적이 있다. 이는 하나의 물리적인 기억 장치를 두 개 이상의 논리적인 기억 장치로 만드는 것을 뜻한다. 리눅스에서 파티션을 만들 때, 각각 파티션은 밑에 있는 그림처럼 나뉜다.

 

 

 물리적으론 하나의 기억 장치이지만 파티션으로 나누게 되면 완전히 다른 공간이 된다. 서로 다른 파일시스템을 가질 수도 있으며, 각각의 파티션은 서로 다른 운영체제를 작동시킬 수 있다. 위 그림을 보면 하나의 파티션 안에 부트 블록이라는 부트스트랩 코드를 담고 있는 영역과 다수개의 블록 그룹으로 나뉜 것을 확인할 수 있다. Ext2 파일시스템에선 탐색 시간을 줄이기 위해 서로 관련된 inode를 인접한 실린더에 배치했고 이를 블록 그룹으로 묶었다.

 

 블록 그룹은 최상위 디렉터리를 담고 있는 슈퍼 블록, 블록 그룹을 설명하는 그룹 디스크립터 외에 여러 영역이 있다. 재밌는 점은 슈퍼 블록과 그룹 디스크립터가 모든 블록 그룹에 존재한다는 점인데, 이는 백업을 위한 용도이다. Ext2 파일시스템을 사용했을 때 디스크에 기록되는 자세한 내용은 다음 그림과 같다.

 

 

Ext3 파일시스템과 Ext4 파일시스템

 

 앞 내용에서 ext2 파일 시스템과 ext3, ext4 파일 시스템의 전체적인 구조나 기본적인 내용은 같다고 언급한 적이 있다. Ext3, ext4 파일시스템에선 사용자의 편의나 성능 향상을 위한 기능들이 추가되었다. 먼저 Ext3 파일시스템에선 어떤 기능들이 추가가 되었는지 살펴 보자.

 

 첫째로는 디렉토리 탐색을 위한 해쉬 기반인 Htree 기술을 도입했다. Linked list로 디렉터리를 연결했던 ext2 파일시스템과는 달리 해쉬 기술을 도입해 디렉터리 내에 있는 파일을 찾는 시간이 주목할만큼 빨라졌다.

 

 다음으로 추가된 기능은 저널링 기법이다. 저널링이란 전원이 불시에 나갈 때를 대비한 기법으로 Journal, Ordered, Writeback 이렇게 세 가지 방법을 지원한다. 자세한 내용은 책 p.147를 참고하시길 바랍니다.

 

 마지막으로 살펴 볼 내용은 LVM(Logical Volume Manager)이라는 기법이다. 한번 파일시스템이 구축되면 동적으로 용량을 늘리거나 줄일 수 없는 ext2에 비해, ext3은 LVM을 도입하여 그것을 가능하게 만들었다.

 

 이제는 최근의 리눅스가 채택하고 있는 ext4 파일시스템이 ext3 파일시스템에 비해 어떻게 성능이 향상되었는지 알아 보자. 첫째로는 파일 생성 시에 미리 일정 개수의 데이터 블록을 할당해주는 선할당(preallocation) 기법과 블록 카운트만 갱신하고 실제 할당은 뒤로 미루는 지연 할당(Delayed allocation) 기법이 있다. 이 둘은 파일시스템의 일관성을 높이고 속도를 향상시키기 위해 도입된 기법이다.

 

 Ext4에는 대용량 파일의 메타데이터를 줄이기 위한 기법이 반영되기도 했다. 만약 파일이 50개의 데이터 블록을 사용한다고 가정하면 아이노드는 direct blocks와 indirect blocks 모두를 사용해 모든 데이터 블록을 향한 포인터를 생성해야 한다. 하지만 Ext4에서는 이를 간략하게 표현해 메타 데이터의 양을 확실히 줄여놨으며 또한 이를 위한 인덱싱 시간도 줄였다.

가상 파일시스템(Virtual File System)

 

 가상 파일시스템을 이해하기 가장 쉬운 방법이 뭘까? 우리는 이전 시간에 메모리 관리에 대해서 배웠으니 그에 빗대서 설명을 해 보자. 우리가 실행 파일을 메모리에 적재하고 프로세스를 실행할 때 우리는 우리가 이 파일을 어느 주소의 물리 메모리에 적재할지 신경쓰지 않아도 된다. 이는 가상 주소가 물리 메모리 어느 곳에 빈 공간이 있는지 알려주고 다른 프로세스와 겹치지 않게 알아서 할당해 주기 때문이다. 가상 파일시스템도 마찬가지이다. 밑에 있는 그림을 보면서 이해해 보도록 하자.

 

 

 위 그림은 전에 설명했던대로 파티션마다 다른 파일시스템을 갖고있는 시스템의 모습이다. 서로 다른 파일시스템은 서로 다른 파일 핸들링 함수를 가지고 있다. 예를 들어, 하드 디스크에 있는 파일을 여는 open() 함수랑 네트워크 파일시스템인 NFS 환경에서 파일을 여는 open() 함수는 하는 일이 당연히 다를 것이다. 그렇다면 유저는 파일이 위치해있는 공간의 파일시스템에 맞춰서 함수를 사용해야 하는 걸까? 그렇지 않다. 가상 파일시스템이 파일의 속성을 읽어서 알아서 맞춤 함수를 호출한다. 어떻게 이런 일이 가능한 걸까? VFS의 동작 원리에 대해서 더 알아 보자.

 

 

 

 위 그림은 ext2 파일시스템을 사용하고 있는 시스템의 예시이다. 사용자 프로세스가 어떤 파일을 읽고 싶어서 함수를 호출하면 가상 파일시스템은 파일의 속성을 읽고 파일이 속해있는 파일시스템을 찾아낸다. 그 이후, 구조체를 하나 생성하고 파일시스템 내에 있는 아이노드 테이블을 뒤져서 파일명과 맞는 파일을 찾아낸다. 파일을 찾은 후에 생성했던 구조체에 그 파일에 대한 내용을 담아서 유저에게 반환한다. 

 

 이러한 일을 하는 가상 파일 시스템은 당연하게도 파일의 메타 데이터를 담을 객체가 필요하다. 그래서 가상 파일 시스템은 슈퍼 블록, 아이노드, 파일 그리고 덴트리 객체 이렇게 총 네 가지의 객체를 갖는다. 슈퍼 블록은 각 파티션마다 있는 파일 시스템의 메타 데이터를 저장하는 곳이라고 배운 적이 있다. 가상 파일 시스템은 슈퍼 블록 객체를 생성해 이를 저장하는 용도로 사용한다. 아이노드 객체 또한 파일마다 존재하는 객체로 파일의 속성 정보를 저장하는 객체이다.

 

 파일 객체 또한 파일의 속성 정보를 저장하는 객체이다. 아이노드와의 차이점이라면 파일 객체는 파일이 열린 상태에서만 사용되는 속성 정보들을 가지고 있다(i.e.파일의 오프셋). 파일 객체는 메모리 상에서만 상주하고 하드 디스크에는 따로 존재하지 않는다.

 

 마지막으로 덴트리 객체는 전에 살펴봤다시피 파일명을 사용해서 파일 객체와 아이노드를 연결해주는 역할을 한다. 책은 덴트리 객체가 일종의 캐시 역할을 한다고 서술했다(..?) (실제로 페이지 캐시 안에 덴트리 캐시와 아이노드 캐시가 있다고 합니다. 하지만 그 역할은 자세히는 모르겠습니다..)

태스크 구조와 VFS 객체

 

 

 위 그림은 사용자 프로세스에서 파일 시스템까지의 경로를 담고 있다. 바로 전에 덴트리 객체가 파일 객체와 아이노드 객체를 이어주는 역할을 한다고 서술한 적이 있는데 위 그림을 보면 쉽게 이해할 수 있다. 위 그림은 task_struct 객체의 file descriptor에서 시작한 후 파일 객체에서 덴트리를 통해 아이노드로 접근 후 파일 시스템까지 도착하는 과정을 보여주고 있다. 각 객체 안에 필드에 대한 자세한 내용은 p.154 - p.156을 참고하시면 됩니다.

 

파일시스템 제어 흐름 분석 

 

 흐름 분석은 설명보다 커널 코드를 보면서 분석하는 게 더 이해하기 쉽기 때문에 생략했습니다. 아래는 전체 VFS 내부 구조입니다.

 

페이지 캐시? 아이노드 캐시? 덴트리 캐시?

페이지 캐시

https://www.oreilly.com/library/view/understanding-the-linux/0596005652/ch15s01.html

아이노드 캐시는 왜 필요한가

https://unix.stackexchange.com/questions/334252/why-is-the-inode-cache-needed

(덴트리 캐시는 아이노드 캐시를 소유하고 있습니다.) https://www.halolinux.us/kernel-reference/the-dentry-cache.html

페이지 캐시

페이지 캐시는 디스크 상의 데이터를 메모리상에 저장한다.. 이 때 “디스크 상의 데이터”는 파일의 내용이 될 수도, 아니면 파일시스템 메타데이터일 수도 있다. 리눅스는 메모리에 여유가 많을 때 많은 양을 페이지 캐시로 사용한다.

 

리눅스는 디스크 IO를 하기 전에 먼저 페이지 캐시에 파일의 내용이 존재하는지 먼저 확인한 후, 있다면 페이지 캐시에서 바로 읽고 없다면 파일을 디스크에서 읽어서 페이지 캐시에 넣어둔다.

 

페이지 캐시가 없다면 같은 파일을 여러 번 읽을 때마다 디스크 IO를 수행해야 하므로 성능이 크게 저하될 수 있다. 데이터베이스와 같은 일부 어플리케이션들은 자신만의 페이지 캐시를 구현하기 위해 리눅스의 페이지 캐시를 사용하지 않고 직접 디스크 IO를 수행하기도 한다. (Direct IO)

 

아이노드 캐시

아이노드도 페이지 캐시와 마찬가지로 디스크 IO를 줄이기 위해서 필요하다. 아이노드가 없다면 (예를 들어) ls를 한번 실행할 때마다 디스크에서 아이노드를 읽어와야 할텐데 (예를 들어 ext2에서는 아이노드가 필요할 때 매번 디스크에서 inode table을 읽어야 할 것이다.), 대신 리눅스는 아이노드 구조체를 메모리 상에 저장해두어서 성능을 향상하고자 한다.

덴트리 캐시

 

덴트리는 파일의 계층구조를 나타내기 위한 자료구조이다. 다시말해 파일과 파일의 트리구조를 나타내는 데 사용된다. 아이노드는 파일의 정보를 나타내긴 하지만, 파일과 파일의 관계를 나타내지는 않는다. 덴트리의 주된 목적은, 파일의 경로에 해당하는 덴트리가 무엇인지 빠르게 변환하는 것이다.

 

덴트리가 없다면 /a/b/c라는 파일 경로는 루트 디렉터리가 가리키는 파일을 읽은 뒤, 거기서 b라는 디렉터리를 찾고, b가 가리키는 파일을 읽고, 거기서 c라는 파일이 어디에 위치하는지 찾아야 한다. 리눅스는 매번 디렉터리가 가리키는 파일을 디스크에서 읽어오는 대신 덴트리라는 자료구조로 파일의 계층구조를 저장하고 빠르게 파일의 경로를 특정 덴트리로 변환한다. 아이노드와는 달리 덴트리는 디스크 상에 저장되는 객체가 아니며 오로지 성능을 위해서 사용된다.

 

페이지, 아이노드, 덴트리 캐시

리눅스는 사용하지 않는 메모리가 있을 때 페이지 캐시, 아이노드 캐시, 덴트리 캐시 등 다양한 종류의 캐시를 사용한다. 아이노드 캐시와 덴트리 캐시는 슬랩 할당자를 통해 관리되며, 페이지 캐시는 페이지 단위로 radix tree의 형태로 관리된다. 이 캐시들은 메모리가 부족할 때 회수되어 다른 용도로 사용한다.

 

4주차 스터디 내용 및 질의응답

[메모리 관리]

• 104p의 4.6 이미지(1)번의 order(1)의 두번째 부분과 세번째 부분이 다른 이유?

-> 5번페이지에는 데이터할당이 불가하고 8,9,10은 연속되어 있어 가능하기 때문

 

• 118p 첫번째 문단에서 1000을 4kb로 나누는데 몫이 왜 0인가요?

-> 1000을 4로 나누는 것이 아니라 4096으로(4kb -> 4096byte) 나눕니다.

 

• mmu랑 커널이랑 같이 메모리 관리를 하는지?

-> 커널이 사전준비를 해서 mmu를 켜주면 실질적인 메모리 관리처리는 mmu가 하게 된다.

 

32(64)bit로 disk의 주소공간을 표현하기가 너무 작은데, 어떻게 disk로 주소공간을  전송하는지?

-> 아키텍쳐마다 다르지만, 메모리 상에 주소를 기록하거나 / 별도의 전송공간이 있다

 

디스크 저장장치의 주소 표현 단위

-> HDD : address*512(size of sector), SSD : address*(size of LBA)

 

[파일시스템과 가상 파일시스템]

•  

• 불연속 할당이 HDD에서처럼 SSD에서도 성능 저하를 불러올까?

  • YES -> WHY?

• 커널 이미지는 별도의 파일시스템에 저장될까? 아니면 루트 파일시스템과 같은 파티션에 있어도 될까?, 후자라면, 부트로더가 임의의 파일시스템을 인식할 수 있는가?

  • “earlier, the presence of the actual kernel image on your root filesystem largely depends on your bootloader's capabilities” https://etutorials.org/Linux+systems/embedded+linux+systems/Chapter+6.+Root+Filesystem+Content/6.4+Kernel+Images 

  •  

• 아이노드 번호는 파일마다 유일하기만 하면 될까? 아니면 디스크 상의 블록에 대한 인덱스여야할까?

  • ext2에서는 아이노드 번호가 그룹의 번호와 inode table에 대한 인덱스임

  • 다른 파일시스템도 비슷…하겠죠?? (잘 모릅니다)

• 연속 할당은 어떤 단위(섹터 or 트랙)로 물리적으로 이어져있을까?

  • N/A

  • 디스크 블록 && 섹터

  • 하지만 섹터 번호가 연속적이더라도 (대체로 물리적으로도 연속이지만) 연속된 번호의 두 섹터가 서로 다른 트랙, 헤더에 있다면 물리적으로 멀 수도 있지 않을까요?

• 커널의 부팅과 파일 시스템

-> MBR에서 커널이 부팅된후 여러가지가 초기화 된 후 ext4 와 같은 파일 시스템이 마운트된다. 이후 /boot 와 하위 파일들이 FAT에 마운트된다(ubuntu 기준임)

 

• 파티션에 별다른 운영체제가 들어있지 않을 때 boot block에는 어떤 값이 들어가있을까?

  • N/A

 

• EXT4 와 HDD : 만약 파일에 modify(add)을 한다고하면 , 다른 공간에 새로 쓰기후 삭제인가, 섹터 위에 쓰거나 add의 경우 sequential 하지 않은 공간에 쓰기를 하는 것인가 ? + extent 기반 데이터 블록 유지 정책을 일관성있게 적용한다면 새로 쓰기후 삭제가 되어아 하겠지만, 실제 implementation이 어떻게 되는지 ?

 

• 왜 EXT4의 open 함수는 NULL일까 ?

  • dentry_open() -> vfs_open() -> do_dentry_open() 순서로 덴트리가 파일과 아이노드를 매핑합니다. vfs_open()에서 do_dentry_open() 함수를 호출할 때 do_dentry_open() 함수는 인자로 struct file, struct inode 그리고 open() 함수를 향한 포인터를 제공합니다. 이때 vfs_open() 함수는 open() 포인터 함수 값에 NULL을 넣어서 do_dentry_open()을 호출합니다. 이는 파일 시스템에 맞는 open() 함수를 호출하기 위함입니다.

  • 코드를 보시면 포인터 함수값이 NULL일 경우 파일 오퍼레이션 필드(f_op)에서 파일 시스템에 맞는 open 함수를 호출하는 것을 확인하실 수 있습니다.

  • 하지만 포인터 함수 값이 NULL이 아닐 경우에 cleanup_all 레이블로 분기하는데 이건 어떤 일을 하는지 잘 모르겠습니당..

 

• d_op, f_op, i_op 의 차이점 ? 

 

2022/06/04 스터디 4주차 사전정리 & 질문

http://embedded.dankook.ac.kr/~baeksj/course/2016_LKI/Chapter_05.pdf

-> 저자 직강 자료

짚고 가고 싶은 부분

• 169p : irq_desc 안에서 하나의 인터럽트를 공유 할 수 있도록 action이라는 자료구조의 리스트를 유지 : 인터럽트를 공유 한다는 의미 ?

http://cms3.koreatech.ac.kr/sites/joo/IFC415/_IFC415_13.pdf

-> 모듈 관련 자료