혼공컴운

[혼공컴운] 15장. 파일 시스템

게으른 the lazy 2024. 8. 2. 22:45

https://www.techtarget.com/searchstorage/definition/file-system

15. 파일 시스템

  • CPU, 메모리, OS의 동작원리 등을 공부하면서 느낀 것을 딱 하나 말하라면, 이렇게 말하겠다.
  • 이게 돌아간다고?!
  • 그것도 수 GHz의 속도로!?
  • 컴퓨터를 설계하는 사람들이 대단하다고는 생각하고 있었지만,
  • 그 존경심이 백 만 배만큼 더 커진 것 같다.
  • 마지막은 파일 시스템이다.
  • 파일 시스템이야 뭐 별거 있나...?
  • 그냥 폴더 있고 파일 있는게 전부 아닌가?
  • ...라고 생각하면 오산이다.

15.1 파일과 디렉터리

  • 내가 생각했던 보조기억장치, 디렉터리, 파일의 구조는 아래 그림과 같았다.

출처: https://wikidocs.net/223730

  • 책장이 보조기억장치이고, 책장 한 칸은 폴더, 상자는 파일이다.
  • 이 그림도 어쩌면 수정해야 할 수도 있겠다.
  • 파티션의 존재 때문인데... 조금 뒤에 설명하겠다.
  • 파일은 그 자체로 정보를 담고 있지만, 파일의 속성도 정보이다.
  • 이 정보는 파일이 직접 갖고 있을 수도 있고, 그렇지 않을 수도 있다.
  • 예를 들어 jpg, png, bmp, tiff는 모두 이미지 파일이다.
  • 파일의 확장자를 jpg에서 png로 바꾸면 png 파일이 될까? 궁금하잖은가?
  • 하지만 그런 일은 일어나지 않는다.
  • 파일 자체가 자신의 포맷 정보를 갖고 있기 때문이다. 아 이거 고급 정보인데...
  • Hex Editor로 png 파일을 열어보면 항상 89 50 4E 47로 시작하는데,
  • 여기서 50 4E 47의 아스키 표를 보면 P N G이다!
  • 비슷하게, bmp 파일은 항상 42 4D로 시작하고, B M에 해당한다.

출처: https://qiita.com/Jun2401/items/779cbdc958f1a57d042d

  • 이런걸 파일 시그니쳐라고 부른다.
  • 여러 파일의 시그니쳐는 이 글을 참고해보자.
  • 하지만 모든 파일이 항상 자신의 속성을 갖고 있지는 않다.
  • 예를 들어 파이썬 코드, C++ 코드, 매트랩 코드 등은 그냥 텍스트 파일이다.
  • 확장자만 언어에 맞게 .py, .cpp, .m으로 되어 있을 뿐이다.
  • 이 파일들은 정말로 코드로서의 텍스트만 갖고 있으므로, 헤더 같은 것은 없다.
  • 그런데 이 파일들도 파일 속성은 있다.
  • 그럼 이 속성 정보들은 어디에 들어가는가?
  • 좀 더 쉬운 예로, 파일명은 어디에 저장될까?
  • 파일명을 바꾼다고 파일의 크기가 달라지지는 않는데?
  • NTFS 기준으로 말하자면, 보조기억장치 내에 MFT(Master File Table)이라는 영역이 있다.
  • 이 영역에 모든 파일과 디렉터리의 정보를 저장한다. (참고)
  • 파일의 속성은 이 곳에 저장되는데, 항상 그런 것은 아닌 듯 하다.
  • 파일의 종류에 따라 달라진다고 한다. (참고)
  • 이 내용은 뒤에서 한번 더 설명하겠다.

15.1.1 디렉터리

  • 윈도우에서는 폴더라고 부르지만, 사실 OS에서의 총칭은 디렉터리이다.
  • 디렉터리는 파일과 다를까? 답: 아니오.
  • 디렉터리는 특별한 파일이다. 파일과 다른 정보를 담고 있을 뿐이다.
  • 그래서 cmd에서 dir을 하면 폴더와 파일이 모두 나온다.
  • 디렉터리는 자신이 담고 있는 파일의 정보를 담고 있다.
  • 이 정보는 보통 표의 형태로 저장되는데, 이것을 디렉터리 엔트리라고 부른다.

출처: https://www.itsmarc.com/crs/mergedprojects/holdings/holdings/directory_hold.htm

  • 여기에는 파일 이름, 위치 정보, 생성 시간, 수정된 시간 등이 저장된다.
  • 디렉터리 내에 디렉터리가 있을 수도 있다.
  • 이 경우에는 하위 디렉터리의 정보가 저장될 것이다.

15.2 파일 시스템

  • 앞에서는 개론적인 내용을 설명했다.
  • 본 절에서는 대표적인 두 파일 시스템인 FAT 파일 시스템과 유닉스 파일 시스템의 차이를 알아본다.

15.2.1 파티셔닝과 포매팅

  • 그러니까... 내가 컴퓨터 부품을 하나하나 사서 직접 조립하던 20년 전(...)에는...
  • 보조기억장치라고 해봤자 HDD밖에 없었다.
  • 당연히 128 GB 2개보다 256 GB 1개가 더 쌌다.
  • 그럼 이제 C와 D를 어떻게 나누느냐의 문제가 생긴다.
  • C를 최소로 해야 D를 넉넉히 쓸 수 있는데, 그렇다고 OS가 돌아가는 C가 너무 작으면 안된다.
  • 그래서 파티션을 잡을 때마다 고민했던 것 같다.

출처: https://recoverit.wondershare.com/partition-tips/format-partition.html

  • 파티션은, 책장으로 비유하자면 크게 구획을 나누는 것이다.
  • 구획을 나눈다고 다 끝은 아니고, 포맷을 해야 한다.
  • 포맷은, 책장으로 비유하자면 칸막이를 달기 위한 핀을 박는 것이다.
  • 주의: 포맷을 한다고 보조기억장치의 모든 정보가 날아가지는 않는다.
  • 포맷은 파일 시스템을 결정하는 것이다. 즉, 일종의 틀을 잡는 것으로 볼 수 있다.
  • 그래서 포맷 한 직후에는 파일을 일부 복구 가능한 것으로 알고 있다. (레퍼런스 필요)
  • 그래서 예전에는 완전히 깨끗이 지우겠다고 로우 레벨 포맷을 걸었다가 남은 시간이 24시간 넘게 나와서(...) 당황했던 기억도 난다.
  • 파티션마다 다른 파일 시스템을 설정할 수 있다.

15.2.2 파일 할당 방법

  • 역시 20년 전에는(...) OS의 온갖 최적화가 유행이었다.
  • 그 덕에 윈도우즈의 구석구석 별별 설정은 다 알게 된 것 같다.
    • services.msc, appwiz.cpl 등의 shell command
    • 시스템 고급 설정에서 시각화 다 끄기 및 가상 메모리 크기 바꾸기
    • system32 폴더 건드리기 등등
  • 그 중 하나가 조각모음이었다.

출처: https://www.youtube.com/watch?v=kWkIzUgX4Ck

  • 물론 지금은 귀찮아서 이런건 하지 않는다.
  • OS가 알아서 해주겠지라는 믿음도 있다.
  • OS는 파일과 디렉터리를 블록 단위로 읽고 쓴다.
  • 보조기억장치에는 엄청난 양의 블록들이 있을 것이다.
  • 이제 파일들을 이 블록들에 어떻게 배치시키냐의 문제가 생긴다.
  • 단순히 앞에서부터 채우면 단편화의 문제가 생길 것임은 너무 자명하다.
  • 그럼 어떻게 처리하느냐?
  • 하나의 파일이 여러 블록으로 떨어질 수밖에 없다면, 다음 블록이 어딘지를 써두면 된다.
    • 연결 리스트(linked list)를 생각하면 된다.
  • 이것을 연결 할당(linked allocation)이라고 부른다.

출처: https://www.scaler.com/topics/file-allocation-methods-in-os/

  • 연결 할당을 변형한 시스템이 FAT 파일 시스템이다.
  • 하지만 이것도 그다지 좋은 방법은 아니다.
  • 파일의 처음이 어딘지를 알아야 줄줄이 찾아가서 중간을 읽을 수 있고,
  • 블록 하나가 고장나면 그 이후는 접근할 수 없는 문제점도 있다.
  • 그래서 나오는 것이 색인 할당(indexed allocation)이다.
  • 이 방식에서는 색인 블록(indexed block)을 별도로 만들어서, 블록의 목록을 적어둔다.
  • 이제 중간도 찾아갈 수 있고, 중간에 블록 하나가 뻑나도 그 이후를 찾아갈 수 있다.
  • 색인 할당 기반으로 만든 파일 시스템이 유닉스 파일 시스템이다.

출처: https://www.scaler.com/topics/file-allocation-methods-in-os/

15.2.3 FAT 파일 시스템

  • 연결 할당의 문제점은, 연결 정보를 블록이 직접 들고 있다는 것이었다.
  • 해결책: 연결 정보를 따로 만들어서 관리하자!
  • 이 연결 정보를 담은 테이블을 FAT(File Allocation Table)라고 부른다.

출처: https://simple.wikipedia.org/wiki/File_allocation_table

  • FAT는 파티션의 앞부분에 만들어진다.
  • 그 뒤로 루트 디렉터리 영역과 데이터 영역이 따라온다.

출처: https://oriont.net/posts/fat12-overview

15.2.4 유닉스 파일 시스템

  • 유닉스 파일 시스템은 색인 할당 기반이다.
  • 즉, 파일들의 블록 번호를 저장한 블록을 따로 만들어둔다.
  • 유닉스 파일 시스템에서 이 블록을 i-node라고 부른다.

https://unix.stackexchange.com/questions/186992/what-is-directory-entry

 

 

  • 색인 방식이 조금 특이한데, 일단 i-node에는 15개의 블록 주소가 저장될 수 있다.
  • 그런데 파일이 점유한 블록이 15개를 넘어가면?
  • 12개는 파일의 블록을 가리키고, 3개는 간접 블록을 가리킨다.
  • 간접 블록에는 또 파일의 블록을 가리키는 인덱스가 적힌다.
  • 만약 이걸로도 부족하면?
  • 간접 블록이 또 다른 간접 블록을 가리킨다.
  • 이런 방식으로 큰 파일에 대한 인덱스를 저장할 수 있다.

15.2.5 저널링 파일 시스템

  • 중요한게 하나 빠졌다.
  • 요즘 윈도우는 아마 NTFS를 많이 사용할 것이다.
  • NTFS는 New Technology File System의 줄임말이다.
  • 파일 시스템을 변경하는 도중에 컴퓨터 전원이 내려가면 파일 시스템이 훼손될 수 있다.
    • 이런 상황을 시스템 크래시라고 부른다.
  • 이것을 방지하기 위해 NTFS에서는 아래와 같이 동작한다.
    • 작업 전에 파티션의 로그 영역에 수행할 작업의 로그를 남긴다.
    • 작업이 정상 완료되었다면 로그는 삭제한다.
    • 시스템 크래시가 발생했다면, 로그 영역의 로그를 기반으로 복구한다.
  • 이것으로 컴퓨터 구조와 운영체제에 대한 개론 공부는 끝났다.
  • 당연히 이 책의 내용만으로는 많이 부족하겠지만, 개괄적으로라도 처음으로 제대로 된 공부를 했다.
  • 이제 CS 관련자들과 조금 더 잘 대화를 할 수 있게 되었다.
  • 다음엔 뭘 공부할까...?
  • 족장님 수고 많으셨어요!
저작자표시 비영리 변경금지