OS(operating system) 개발하고자 하면서...

글을 쓰는 이유

 

system software 그 중에서도 OS개발자가 되고 싶은 글쓴이가 파악한 것들에 대해 적는다.

 

 

문제 파악

 

최근에 보고 있는 논문에서 제안한 문제이다.

(실제 내용 및 절차와 다를 수 있고 절대 정답이 아니다. 하지만 이 글은 OS개발에 대해 어떤 것들을 생각해 보았는지 적은 글이다.)

zns ssd라는 새로운 하드웨어 기술이 등장했다.

이는 ssd에 zone을 설정해 사용자(프로세스, 컨테이너 등등의 단위)가

특정 하드웨어의 부분만을 사용하기 위함인데.

이때 기존에 있던 filesystem이나 커널의 구조가 호환이 안된다는 문제가 있다.

되더라도 zns ssd에 맞는 구조를 갖고 있지 않기 때문에 비효율적인 입출력이 문제이다.

또한 기존에 dm-zoned(dm-mapper)라는 호환가능한 시스템이 있지만

zns ssd는 여전히 이 시스템에서 효율적으로 작동하지 않는다고 한다.

 

 

그래서 뭘 개선하는 건데?

 

사실 이 문제를 답하려면 논문에서 제시한 이유를 알아야 한다.

최근 널리 사용되는 클라우드 분야에서 컨테이너에서 시작한다.

컨테이너는 애플리케이션을 쉽게 배포, 수정, 스케일 out or in 등에 기본적으로 사용 되는 개념이다.

이는 애플리케이션을 클라우스 서버에서 컨테이너 단위로 생성하고 실행할때

엄청나게 큰 클라우드 시스템 리소스(storage, cpu, memory 등)을 하나의 애플리케이션이 전부 사용하지 않고 다른 애플리케이션과 엉키지 않고 고립되게 한다.

그 과정에서 linux의 커널이 개입한다. 이유는 하드웨어를 제어하는 것은 커널이기 때문이다.

linux 커널이 컨테이너를 고립적으로 만들게 도와주는 cgroup이라는 linux kernel subsystem 이 있다.

cgroup은 storage, cpu, memory등을 프로세스 그룹에게 적절히 할당해준다.

cgroup의 기능 중 storage 분배를 도와주는 blkio라는 subsystem이 있다.

BFQ스케줄러(block device io 스케줄러)는 각 cgroup에 할당된 weght(가중치)를 입출력 대역폭을 분배한다.

만약 3개(A, B, C)의 컨테이너가 있고, 클라우드 시스템의 입출력 대역폭이 2400iops 이라하면

A.weghit : 200

B.weghit : 400

C.weghit : 600

1초당 A는 400iops, B는 800iops, C는  1200iops를 가질 수 있을 것이다.

 

이제 문제를 다시 생각해 보자.

filesystem의 BFQ스케줄러(block device io 스케줄러)가 device를 고려하여 동작하기 때문에

이 가중치 비례 입출력이 zns에서는 동작하지 않는다고 한다.

 

 

개발자가 해야할 일

 

현재의 fs으로 zns를 동작시키기 위해서 무엇을 해야 하는지 알게 되었다.

이제부터 시작이다. 

개발자는 커널 코드를 보며 zns를 바르게 동작시키고 효율적으로 사용하기 위해서

코드를 수정하고, 빌드하여 테스트 해봐야 한다.