Chanhae Oh

빅데이터, 분석

파일시스템



파일시스템은 저장장치 내에서 데이터를 읽고 쓰기 위해 미리 정해진 약속 이라고 볼 수 있다.

즉 미리 정해진 약속, 규약이라고 보면 될것으로 생각 된다.

파일 시스템은 저장할 데이터를 결정하고, 그 크기와 위치 등을 미리 약속한 뒤 운영체제 등에서 그대로 사용하면 된다.

물론 실제 파일시스템의 데이터 구조는 방대하고, 복잡하겠지만 결국 ‘미리 약속한 방법으로 저장하고 읽어 들이는 것’이다.


파일시스템들의 특징이 서로 다른 것 처럼 각각의 용도에 따라 선택을 달라지게 하는 것이 좋다.

  1. 제품과 PC의 호환

만약 USB 메모리가 있다고 했을 때 이 메모리가 윈도우랑 호환이 되지 않아 일일이 드라이브를 설치해야 한다면 과연 널리 사용될 수 있을까? 어떤 제품이 사용자 PC에서 바로 인식 가능해야 한다면 제품 제작 시 PC와 호환 가능한 파일 시스템을 사용하는 것이 바람직 할 것이다.

  1. 보안

이번에는 메모리가 누구도 열람해선 않된다고 했을 때 메모리를 분실하거나 도난 당하게 되면 치명적일 것이다. 이 경우에는 특정 PC에서만 USB 메모리를 열람 가능하게 하는 것이 좋을 것인데 이럴 경우 독자적인 파일 시스템을 제작하는 것이 현명 할 것이다.

  1. 성능

개발하고자 하는 제품의 스팩 및 특징에 따라 파일시스템의 성능이 중요한 요소로 작용한다면 독자적 파일 시스템을 고려해볼 필요가 있을 것이다.

  1. 어플리케이션 레벨의 속성

만약 권한 설정 및 보안 기능이 필요할 경우 NTFS를 사용해야 하며, FAT32에서는 파일시스템 자체로 보안 기능을 사용할 수 없게 될 것이다. 이 경우 성능의 문제와도 관련이 있을 것이다. 보안 기능 등 여러 특징이 있는 NTFS는 비교적 느린 성능의 PC에서는 FAT32 보다 눈에 띄게 성능차이를 보일 것이다. 그러나 파일 검색을 위해서라면 NTFS를 선택하는 것이 올바를 것이다.

사실 실제로 제품 개발 시 의외의 요소가 파일시스템의 선택의 영향을 미칠 것이다. 파일 시스템은 제품에 포팅한 뒤에 변경하는 과정에서 특히 손이 많이 가는 작업이기 때문에 제품 설계시 파일시스템의 선택에 심사숙고 해야할 것이다



목차


1. 일반적인 파일시스템


FAT(File Allocation Table) 파일시스템


  • 마이크로소프트사의 빌게이츠가 만들었으며 전 세계적으로 가장 많이 사용되는 파일시스템
  • 초기에 만들어졌으며 여러 번 발전을 거듭해 왔지만, 최초 제작 당시에는 고려하던 저장 장치의 크기가 매우 작았으며 성능상 문제는 큰 이슈로 작용하지 않음.
  • 매우 단순한 구조를 지니고 있으며 최근엔 대용량 저장을 위해 FAT16, FAT32 이 만들어진 이 후 윈도우 OS의 흥행과 더불어 지금도 널리 사용되고 있다.
  • FAT파일시스템의 범용성은 휴대용 장치들과 PC와의 호환성을 높여주는 결과를 가졌으며, 이동식 저장장치들은 FAT파일시스템을 설치하기만 하면 별도의 설치과정 없이 엔드유져(End User)들의 PC에서 간편하게 읽어 들일 수 있게 만들어 짐.
  • 파일시스템에서 사용되는 부가 기능은 적고, 제약사항들은 많은 단점이 있으나 그만큼 가볍고 심플하다.
  • 단점으로는 연결 리스트를 사용한 자료구조로 인해 검색시간이 오래 걸리고, 파일 데이터 블록들이 여기저기 흩어지는 단편화 현상이 심해져 한파일의 데이터를 읽어 들이는 데도 디스크 헤드가 여러 번 이동하게 만들어짐.
  • 디스크 조각 모음 등의 부가적인 프로그램이 등장하였지만 근본적인 해결책이 되지 않아 서버 시스템 등에서 사용되기에는 여러 가지 부족함이 많은 파일시스템이기 때문에 이후 여러 파일시스템들이 이를 개선하기 위해 등장하게 됨.



HPFS(High Performance FileSystem)

  • IBM의 OS/2 1.2 부터 사용된 파일시스템이며 NTFS가 나오기 까지 많은 영향을 준 파일시스템.
  • 제작 당시부터 대용량 디스크에 적합한 구조를 지니고 있으며, 효율적인 캐싱과 FAT파일시스템에 비해 파일 손실과 단편화가 적고, 서버 시스템에 사용할 수 있도록 여러 가지 보안 기능 등에 대한 요구를 충족시켜 줄 수 있는 파일 시스템이다.
  • 대용량 저장 장치를 타켓으로 하였기 때문에 200MB 미만의 저장장치에서는 성능저하를 가져올 수 있는 단점이 있으며, 섹터 크기가 512Byte로 고정되었기 때문에 기본 데이터 I/O 단위를 변경할 수 없다.
  • OS/2가 윈도우 NT와의 경쟁에 밀려 흥행에 실패하였고, 윈도우 NT 4.0부터는 HPFS를 지원하지 않아 호환이 불가능하여 우수한 성능 및 발전 가능성에도 불구하고 비운의 파일시스템이 됨.



NTFS(New Technology FileSystem)

  • 마이크로소프트사의 서버급 운영체제인 Windows NT에 사용되는 파일시스템.
  • 윈도우 NT 및 2000 이상의 OS에서 대표적인 파일시스템으로 자리 잡아 서버 시스템은 물론 일반 PC에서도 널리 사용되고 있다.
  • NTFS는 대용량 저장장치를 겨냥해서 제작 되었으며, 높은 안정성과 부가기능 지원하고, FAT와 HPFS에 있던 여러 제약 사항들을 크게 개선한 파일 시스템이다.
  • 제작사인 마이크로소프트사에서 전체 스팩을 공개하지 않아 완벽한 분석이 이루어지지 않았으며, 이로 인해 리눅스 등의 다른 OS에서 NTFS를 지원 한다고 해도 미흡한 부분이 있을 수밖에 없다.



UFS(Unix FileSystem)

  • 유닉스의 대표적인 파일시스템으로 현재까지 쓰이는 대부분의 유닉스에서 사용되는 파일시스템의 근간이 됨.
  • BSD계열(FreeBSD, NetBSD, OpenBSD 등)은 물론 HP-UX, Apple OS X, Sun Solaris에 이르기 까지 많은 유닉스 계열의 OS들이 UFS를 각각의 OS에 맞게 변형해서 사용하고 있다.
  • UFS는 빠른 속도와 높은 안정성을 목표로 만들어짐.
  • 저장장치를 그룹화하여 관련된 데이터끼리는 최대한 가까운 위치에 자리할 수 있는 구조로 되어 있어 디스크 헤드의 이동이 비교적 적고, 중요한 데이터는 이런 그룹에 걸쳐 많은 백업을 저장하므로 만일의 사태에 대하여 보다 신뢰성을 높임.
  • 미국 Berkeley 대학의 FFS(Fast FileSystem)에서 근간을 이루었으며, Bell 연구소에서 Unix Version7을 개발할 때부터 본격적으로 UFS라는 명칭을 사용하였다. UFS는 리눅스 파일 시스템인 Ext2 에 큰 영향을 미치게 된다.



Ext2파일 시스템(Second Extended FileSystem)

  • 현재 리눅스의 기폰 파일시스템인 Ext3에서 저널링 기능을 뺀 파일 시스템으로서 UFS를 근간으로 하고 있다.
  • UFS에서 유명무실한 구조들은 제거하고, 전체적인 구조를 보다 간략히 한 Ext2는 비교적 명료하고 간단하면서 UFS의 속도와 안정성을 고류 갖춘 파일 시스템이다.
  • 현재까지도 리눅스 기본 파일시스템으로 자리잡고 있는 Ext3에서 그대로 사용 되고 있다.



목차로



2. 플래시 파일 시스템


  • 플래시 파일시스템(Flash FileSystem)의 특징은 플래시 메모리의 특성에 최적화되어 있다.
  • 플래시 메모리는 블록(Block)구조로 되어 있는데 읽는 것은 블록과 관계없이 바이트 단위로 자유롭지만, 쓰거나 지우는 것은 언제나 블록 단위로 해야만 한다. 이런 블록의 크기는 꽤 큰 편이여서 보통 64~128kb까지 된다.
  • 플래시 메모리의 특징은 블록에 쓰기를 할 수 있는 횟수에 제한이 있다. 보통 10,000~100,000번 정도를 수명으로 본다. 이 수명은 플래시 메모리의 수명이 아니라 블록의 수명이다.
  • 만약 어떤 플래시 메모리에 블록이 10개고, Write 횟수가 100,000일 경우 이 플래시 메모리에 블록 하나에 충분히 들어갈 만한 크기의 작은 데이터 하나만 기록한다고 했을 때 이 경우 블록을 돌려가면서 데이터를 쓰게 되는데 그 플래시 메모리의 수명은 100,000번 X 10블록 = 1,000,000번이 될 것이다.
  • 임베디드 시스템에 담긴 플래시 메모리의 구조에 호환성은 별로 중요하지 않기 때문에 자체적으로 필요한 구조의 플래시 파일 시스템을 구현하여 제품에 올릴 경우가 만을 것인데 이때 임베디드 리눅스를 사용하게 된다면 JFFS2나 YAFFS 파일시스템을 주로 이용하게 된다.
[목차로](#home1)



3. 네트워크 파일 시스템


  • 네트워크 파일시스템(Network FileSystem)은 1984년 Sun Microsystems에서 원격에 위치한 파일시스템을 로컬 파일시스템처럼 이용할 수 있도록 개발한 프로토콜이다.
  • 단순히 파일 공유 차원의 것이 아니라, NFS도 결국 파일 시스템임을 인지 해야 하기 때문에 원격 파일시스템이 마운트되면 마운트 지점이 아래 위치한 파일에 접근을 하는 경우 NFS가 파일시스템 레벨에서 시스템 콜을 받아 직접 네트워크 파일을 수신하여 로컬 영역에 파일을 쓰거나 직접 실행할 수 있도록 한다.
  • NFS의 초기 버전에서는 UDP 통신만 가능 했으나 이후 TCP도 지원하며, 파일 크기를 64bit까지 지원하여 4GB가 넘는 파일도 NFS로 이용 가능 하다.



목차로



4. 가상 파일 시스템


  • OS 차원에서 가상 파일시스템(Virtual FileSystem)이라는 상위 레벨의 파일시스템 인터페이스가 존재하기 때문에 응용프로그램에서는 아무 구분 없이 OS 의 시스템 콜을 호출하면 커널은 미리 등록되어 있는 파일시스템 함수를 호출하여 그 종류에 상관없이 같은 결과를 볼 수 있다.
  • 만약 가상 파일시스템이 없다면 일단 OS를 설치하고 나면 다른 파일시스템이 설치된 파티션을 인식할 수 없을 뿐만 아니라 다른 파일시스템의 인식을 위해서 별도로 컴파일 된 파일시스템 모듈을 덮어씌워야 할 것이다.
  • 가상 파일 시스템은 로컬 영역이나 원격 영역의 파일시스템을 실제로 제어하지 않기 때문에 OS 부팅 시에 시용 가능한 파일시스템 함수를 가상 파일시스템 쪽으로 등록해 주어야 한다. 일반적으로 하드디스크에서 사용하는 파일시스템뿐 만 아니라 CD-ROM 파일시스템과 네트워크 파일시스템 등 기본적으로 등록하는 파일시스템이 여러 가지 있다.
  • 가상 파일시스템의 아이디어가 최초 적용된 OS는 1986 년 Sun Microsystems 의 SunOS 2.0 이다. 당시 SunOS 에서 로컬 영역의 UFS와 Remote 영역의 NFS를 통시에 지원하면서 그 개념이 도입되었고, 이후 대부분의 유닉스 계열의 OS들이 가상파일시스템을 지원하였다.



목차로



5. 파일시스템 요소들


5.1 기본요소


  • 파일시스템은 커널 또는 응용프로그램에서 저장하고자 하는 데이터를 저장장치에 기록하기 위한 방법을 제시하므로 이에 필요한 저장장치 및 논리적 요소들을 알아볼 필요가 있다.


5.2 클러스터


  • OS가 파일시스템 생성 시 저장장치의 크기를 고려하여 클러스터의 크기를 조절한다.
  • 저장장치의 크기 및 사용 용도에 따라서 달라져야 한다.
  • OS에 의해 데이터를 읽고 쓰는 과정에서 파일시스템은 미리 정해져 있는 클러스터의 크기를 기본단위로 하여 읽고 쓰는 과정에서 입출력을 하게 된다.
  • 클러스터의 크기가 4096Byte라면 1Byte를 읽더라도 4096Byte를 읽어야 한다. 단순히 읽는 거라면 문제가 되지 않지만 쓰는 경우에는 문제가 될 수 있다.
  • 위 그림처럼 크기가 작은 파일을 저장할 경우 낭비되는 영역이 생기는데 이 부분의 공간은 사용이 불가능 해진다.
  • 위처럼 낭비되는 공간이 있음에도 클러스터의 크기를 정하는 이유는 성능적인 측면 때문에 있다. PC사용시 처리속도에 있어 가장 큰 비용을 요구하는 작업은 디스크 입출력이다.
  • 만약 10KB 파일을 읽을 경우 클러스터가 1KB라면 10번 I/O가 발생해야 하지만, 클러스터 크기가 4KB라면 3번의 I/O로 읽을 수 있을 것이다. 이 경우 2KB가량이 낭비되지만 요즘같이 대용량 하드라면 무시할 수 있을만한 정도이다.

  • 파일시스템 역량과 저장장치 크기에 따라 클러스터의 크기가 저장장치 사용에 중요한 요소가 될 수 있다. 예를 들어 FAT16과 같이 파일시스템 주소 지정 방식에 16Bit를 사용하는 상황이라면 클러스터의 크기에 따라 최대 사용할 수 있는 저장장치의 공간이 차이를 보일 수 있다.

    • 클러스터의 크기가 1KB라면 저장장치의 크기는 65,536(216) X 1,024(1KB) = 64MB

    • 클러스터의 크기가 4KB라면 저장장치의 크기는 65,536(216) X 4,096(4KB) = 256MB 가 될 것이다.

  • 32Bit, 48Bit, 64Bit 등 다양하게 사용되지만, 저장장치의 크기가 작고 가격이 비싸던 시절에는 상황에 따라 충분히 문제가 될 수 있다.
  • 일반적으로 클러스터의 크기는 디스크를 포맷할 경우나 파일시스템을 생성하는 시점에 지정할 수 있으며, 최근의 대용량 하드에서는 주로 4KB의 크기가 기본으로 지정되어 있다. 플로피의 경우 기본 1KB로 지정되어 있다.


5.3 파일


  • 파일시스템이란 결국 파일을 기록하기 위한 것이므로 파일을 이루는 구조와 그것을 관리할 수 있는 추가적인 방법을 제시하는 것이다.

  • 파일은 속성을 기록하는 메타 데이터 영역, 실제 데이터를 기록하는 데이터 영역으로 나눌 수 있다.

  • 메타데이터는 파일시스템에서 파일을 관리할 수 있는 정보 자체를 말하며 파일의 속성을 물론 실제 데이터를 기록한 위치를 찾아가기 위한 정보를 포함하며, 파일 시스템들은 이런 정보들을 어딘가에 저장해두고 OS가 정보 요청 시 해당 파일을 찾아서 정보를 조합하여 넘겨주면 사용자가 파일이라고 부르는 정보가 되는 것이다.

  • 파일 데이터는 클러스터 단위로 읽고 쓸 수 있으며, 단 1Byte라도 사용한다면 1개의 클러스터 영역이 사용된다. 최근 하나의 클러스터에 여러 파일 정보를 담을 수 있는 연구가 진행중이며, 현재 스펙상 이것이 가능한 파일시스템도 있지만, 실제 사용되는 경우는 없다.

  • 모든 파일시스템은 파일 정보를 관리하는 자료구조를 가지며, 이 자료구조에 의해 파일시스템의 성능에 큰 영향을 끼치게 된다.

  • FAT의 경우 연결리스트, NTFS는 B-Tree를 사용하며, 두 알고리즘의 특성과 마찬가지로 검색기능에 있어 NTFS가 FAT에 비해 효율이 좋은 것처럼 여러 가지 차이를 보인다.


5.4 디렉토리


  • 파일들을 계층화하고 그룹화 할 수 있는 개념으로, 상, 하위 개념의 디렉토리와 파일들은 관리하는데 있어 많은 이점을 제공하며, 때로는 이런 개념을 뛰어넘기 위한 링크(Link) 등의 방법을 제공하는 파일 시스템도 있다.
  • 파일과 디렉토리에 대한 속성 정보를 따로 만들어 놓고 이를 통해 파일과 디렉토리를 구분하여 관리하지만, 실제 안을 들여다 보면 결국 비슷하다.
  • 파일의 경우 데이터 영역에 있어 파일 정보에서 그것의 위치를 가리키며, 디렉토리의 경우도 데이터 영역이 존재하는데 이 영역에는 하위 존재하는 디렉토리 및 파일 리스트 들이 있다.
  • 가장 상위 디렉토리의 경우 파일시스템에 따라서 관리하는 방법이 다르므로 해당 파일 시스템의 분석을 살펴보도록 해야한다.



목차로



6. 부가 요소


소유권

  • 개인용 컴퓨터와 서버용 컴퓨터에서 사용하는 파일시스템간의 두드러진 차이점 중의 하나는 파일마다 그룹과 소유권을 따로 관리할 수 있다는 점이다.
  • 한대의 컴퓨터에 여러 명의 사용자가 접근하는 경우 각 사용자들의 파일에 대한 접근 권한을 따로 관리할 필요가 있으며 시스템 관리자의 입장에서도 사용자들이 아무 제제 없이 시스템 파일에 접근하는 것을 막아야 한다.
  • FAT파일시스템에서는 소유권을 관리할 수 없기 때문에 OS차원에서 제한을 두는 것은 한계가 있다.(Win 98의 경우 사용자 계정을 달리 로그인할 수 있지만, 정작 그들간의 접근할 수 있는 파일에는 제한이 없다.)
  • NFTS나 EXT2를 비롯한 서버급 파일시스템은 모든 파일에 사용자 그룹과 소유권한을 부여할 수 있어 사용자가 시스템 파일에 허가 없이 접근하는 것을 막을 수 있다.


동기화

  • 현재 모든 OS들은 멀티태스킹(Multi-Tasking) 기능을 지원하여, 하나의 CPU에서도 여러 프로그램이 동시에 실행되는 것처럼 동작한다.
  • 이때 주의할 점이 동기화 작업이다. 하나의 파일에 여러 프로세스가 동시에 접근해서 작업을 하는 경우 파일에 락(Lock)을 걸어주고, 적절한 시점에 해제하는 동기화가 진행되어야 하는데, 파일시스템을 제작하면서 동기화만큼 손이 많이 가는 작업이 드물다.
  • 여러 가지 상황에 따른 고민과 여러 가지 상황의 문제가 생길 수 있기 때문에 많은 시간이 소요된다. (만약 A라는 파일에 삭제 명령을 하고 동시에 A라는 파일을 읽기 명령이 진행 되었을 경우 A라는 파일이 락이 걸려있지 않다면 삭제되고, 읽을때 잘못된 포인터 접근하여 세그먼테이션 오류를 발생 시킬 수 있다.)
  • 최근에 사용되는 파일시스템들은 대부분 파일에 락을 걸 수 있도록 스펙이 정의되어 있는데 락에는 그 유형과 적용 해야하는 위치가 다양하기 때문에 파일시스템을 제작할 경우 각별히 신경써서 구현해야 한다.

일관성(Consistency) 체크와 저널링

  • 예기치 못한 상황에서 시스템이 멈추거나 정전이 일어날 경우 문제가 발생하는데 파일을 쓰고 있었다거나, 중요 업데이트를 하고 있을 경우 실제 파일이 없는데 있는 것처럼 표시되어 데이터가 잘 못될 수 있는 등 일관성이 깨지게 된다.
  • 가장 우선적으로 파일시스템 구현 시 이런 상황을 대비 해야하며, 파일을 쓸 때 메타데이터와 파일 데이터를 쓰는 순서를 시스템 Crash 상황을 고려 해야한다.
  • 메타데이터를 먼저 쓰고, 파일 데이터를 쓰게 될 경우 파일 데이터 쓰는 도중 시스템 중단되면 파일이 있는 것처럼 보이겠지만 실제론 없을 것이다. 그러나 반대로 파일 데이터를 먼저 쓰고 메타데이터를 쓸 경우 시스템이 중단이 되어도 메타데이터가 나중에 쓰여지기 때문에 파일리스트에 없을 것이며, 해당 파일데이터가 쓰여진 곳은 어차피 빈 영역이고, 나중에 다른 데이터가 쓰여지게 될 것이다.
  • 파일시스템 일관성 문제가 발생했을 경우 별도의 유틸리티 프로그램이 요구된다. chkdsk.exe(FAT, NTFS), e2fsck(Ext2) 등이 있다.
  • 이런 프로그램은 파일시스템 내에 존재하는 모든 메타 데이터를 검색하여 문제가 있는 부분은 수정한다. 그러나 요즘 같은 경우 용량이 크기 때문에 시간이 많이 걸릴 수도 있다. 이런 상황을 위해 대두된 것이 저널링 기능이다.
  • 저널링은 데이터베이스에서 일관성 체크를 위해 사용되는 방법을 파일시스템에 적용한 것으로 파일시스템 업데이트 시에 로그를 기록하고, 문제가 생길 경우 해당 로그를 참조하여 업데이트를 취소할 수 있고, 파일시스템에 적용완료(commit)할 수 있다.
  • 저널링 기능의 큰 장점은 업데이트 로그를 기록하고 있기 때문에 일관성 체크를 위한 파일시스템의 전 영역을 검색하지 않아도 되며, 해당 로그만 찾아가서 작업을 수행하면 된다. 따라서 시간이 많이 단축될 것이다.

보안

  • 파일의 소유 권한과 실행 권한 등을 다루는 방법.(OS등을 통해 파일시스템에 접근하는 상황에 해당될뿐 물리적으로 접근시 데이터가 들어남)
  • 파일시스템 암호화 기법으로 암호화를 적용하는 계층은 가상 파일시스템과 파일시스템 자체에서 할 수 있다. 또는 메타 데이터만을 암호화 하는 경우와 파일 영역까지 압축을 통한 암호화를 진행하기도 하며, 디렉토리 및 파일 등을 선택해서 적용할 수 있다.



목차로