파일 시스템 플래그멘테이션

File system fragmentation
조각화 및 조각 모음 시각화

컴퓨팅에서 파일 시스템 플래그멘테이션(파일 시스템 에이징이라고도 함)은 파일 시스템의 콘텐츠를 비연속적으로 배치하여 파일 내용을 내부 수정할 수 있도록 하는 경향이 있습니다.이것은 데이터 플래그멘테이션의 특수한 경우입니다.파일 시스템 조각화는 회전하는 스토리지 미디어의 탐색 시간에 부정적인 영향을 미치며, 이는 스루풋을 저해하는 것으로 알려져 있습니다.조각화는 파일을 재구성하여 인접 영역에 여유 공간을 다시 확보함으로써 해결할 수 있습니다. 이 프로세스를 조각 모음이라고 합니다.

솔리드 스테이트 드라이브는 물리적으로 탐색하지 않기 때문에 비순차적 데이터 액세스가 이동하는 드라이브보다 수백 배 더 빠르기 때문에 단편화가 문제가 되지 않습니다.솔리드 스테이트 스토리지의 조각 모음을 실시하지 않는 것이 좋습니다.이는 불필요한 쓰기-삭제 [1]조작에 의해 드라이브가 조기에 마모될 수 있기 때문입니다.

원인들

파일 시스템을 파티션에서 처음 초기화할 때 파일 시스템은 몇 개의 작은 내부 구조만 포함하고 그렇지 않으면 연속된 빈 [a]공간 블록 중 하나입니다.즉, 파일 시스템은 새로 생성된 파일을 파티션의 아무 곳에나 배치할 수 있습니다.생성 후 한동안 파일을 거의 최적으로 레이아웃할 수 있습니다.운영체제와 응용 프로그램을 설치하거나 아카이브를 풀면 관련 파일이 서로 가까이 배치되도록 개별 파일이 순차적으로 발생합니다.

기존 파일이 삭제되거나 잘리면 사용 가능한 새 영역이 생성됩니다.기존 파일이 추가되면 다른 파일이 이미 할당되어 있을 수 있기 때문에 파일 종료를 위해 쓰기를 재개할 수 없는 경우가 많습니다.따라서 새로운 fragment를 할당해야 합니다.시간이 지남에 따라 동일한 요소가 지속적으로 존재하게 되면 빈 공간과 자주 추가되는 파일이 더 많이 조각화되는 경향이 있습니다.또한 빈 영역이 짧아지면 파일 시스템이 새로운 파일을 연속적으로 할당할 수 없게 되어 분할해야 합니다.특히 파일 시스템이 꽉 차서 사용 가능한 공간이 많은 인접 영역을 사용할 수 없는 경우에 그렇습니다.

예

빈 공간 플래그멘테이션 및 파일 플래그멘테이션이 발생하는 간단한 예

다음 예시는 복잡한 주제를 단순화한 것입니다.다음 시나리오를 고려합니다.새 디스크에는 A, B, C, D 및 E라는 이름의 5개의 파일이 연속적으로 순차적으로 저장되어 있습니다.각 파일은 10블록의 공간을 사용합니다.(여기서 블록 크기는 중요하지 않습니다.)나머지 디스크 공간은 1개의 빈 블록입니다.따라서 E 파일 뒤에 추가 파일을 생성하여 저장할 수 있습니다.

파일 B 를 삭제하면, 10 블록의 빈 영역이 생성되어 디스크가 fragment화 됩니다.빈 공간은 그대로 두고 나중에 사용할 수 있도록 표시한 후 [b]필요에 따라 다시 사용합니다.삭제 직후에 파일 시스템이 디스크를 조각 모음할 수 있지만, 그렇게 하면 예기치 않은 시간에 심각한 성능 저하가 발생할 수 있습니다.

이제 7블럭의 공간이 필요한 F라는 새로운 파일을 이전에 파일 B를 보유하고 있던 새로 해방된 공간의 처음 7블럭에 배치할 수 있으며, 그 뒤의 3블럭은 계속 사용할 수 있게 됩니다.3블록만 필요한 G라는 새로운 파일이 추가되면 F와 C 앞에 공간을 차지할 수 있습니다.

나중에 F를 확장해야 할 경우 F 바로 다음 공간이 사용되므로 파일 시스템에는 다음 세 가지 옵션이 있습니다.

  1. 다른 곳에 새 블록을 추가하고 F에 두 번째 익스텐트가 있음을 나타냅니다.
  2. F를 연속적으로 유지할 수 있도록 파일을 다른 곳으로 이동
  3. 파일 F를 이동하면 새로운 사이즈의 연속된 파일 1개가 됩니다.

두 번째 옵션은 파일 크기가 매우 큰 세 번째 옵션과 마찬가지로 성능상 실용적이지 않을 수 있습니다.세 번째 옵션은 새 파일을 저장할 수 있을 만큼 큰 단일 연속 빈 공간이 없는 경우 사용할 수 없습니다.따라서 일반적인 방법은 단순히 다른 곳에 익스텐트를 만들고 새로운 익스텐트를 기존 익스텐트에 연결하는 것입니다.

파일 F의 끝에 추가된 재료도 같은 범위의 일부입니다.그러나 재료가 너무 많아 마지막 익스텐트 이후 빈 공간이 없을 경우 다른 익스텐트를 생성해야 합니다.결국 파일 시스템은 많은 장소에 빈 세그먼트를 갖게 되고 일부 파일은 여러 익스텐트에 분산될 수 있습니다.이러한 파일(또는 모든 파일)의 액세스 시간이 과도하게 길어질 수 있습니다.

필요성

일부 초기 파일 시스템에서는 파일을 fragment화할 수 없었습니다.그러한 예 중 하나는 BBC Micro에서 사용되는 Acon DFS 파일 시스템입니다.파일을 fragment화할 수 없기 때문에 "확장할 수 없습니다"라는 오류 메시지가 나타날 수 있습니다.또한 디스크에 충분한 공간이 있어도 파일을 저장할 수 없는 경우가 많습니다.

DFS는 매우 단순한 디스크 구조를 사용했으며 디스크 상의 파일은 길이와 시작 섹터별로만 배치되었습니다.즉, 모든 파일이 연속적인 섹터 블록으로 존재해야 했고 조각화가 불가능했습니다.위의 표의 예를 사용하면 스텝5에서 파일F를 확장하려고 하면가 확장되지 않습니다.에러 메세지가 표시되며, 이러한 시스템에서 실패했을 가능성이 있습니다.디스크에 남아 있는 총 여유 공간의 양에 관계없이 데이터 파일을 확장할 수 없었습니다.

당시 오류 처리 기준은 원시적이었고, 어떤 경우에도 BBC Micro의 제한된 메모리에 압축된 프로그램은 오류를 적절하게 처리하려고 공간을 낭비할 여유가 거의 없었습니다.대신 사용자는 명령 프롬프트에서 Can't extend(확장할 수 없습니다) 메시지가 표시되며 파일에 추가되지 않은 모든 데이터가 손실됩니다.이 문제는 디스크의 빈 공간을 미리 확인하는 것만으로 해결할 수 없었다.디스크상의 빈 영역이 존재하는 경우도 있습니다만, 디스크 카탈로그에 기재된 수치를 분석하지 않으면 빈 영역의 가장 큰 연속 블록의 사이즈가 곧바로 표시되지 않기 때문에, 유저의 눈에 띄지 않게 됩니다.또한 거의 모든 DFS 사용자가 이전에 카세트 파일 저장소를 사용했으므로 이 오류가 발생하지 않습니다.플로피 디스크 시스템으로의 업그레이드는 비용이 많이 드는 업그레이드이며, 경고 없이 업그레이드할 경우 데이터 [2][3]손실이 발생할 수 있다는 것은 충격이었습니다.

종류들

파일 시스템의 플래그멘테이션은 다음과 같은 몇 가지 수준에서 발생할 수 있습니다.

파일 플래그멘테이션

개별 파일 조각화는 단일 파일이 여러 조각(Extent 기반 파일 시스템에서 익스텐트라고 함)으로 분할될 때 발생합니다.디스크 파일 시스템은 개별 파일을 연속적으로 유지하려고 하지만 성능 저하가 심하지 않으면 불가능한 경우가 많습니다.파일 시스템 검사 및 조각 모음 도구는 일반적으로 "조각화 비율" 통계에서 파일 조각화만 고려합니다.

여유 공간 조각화

파일 시스템에서 새 파일 또는 메타데이터를 쓸 수 있는 사용되지 않는 영역이 여러 개 있는 경우 여유 공간 조각화가 발생합니다.불필요한 빈 영역의 플래그멘테이션은 일반적으로 파일의 삭제 또는 절단에 의해 발생하지만, 파일 시스템은 인접한 파일의 확장을 용이하게 하기 위해 의도적으로 빈 영역의 fragment("버블")를 삽입할 수도 있습니다(아래의 fragment화 방지 참조).

파일 산란

다음 항목도 참조하십시오.파일 시퀀스

파일 세그먼트화는 관련 파일 플래그멘테이션 또는 응용 프로그램레벨(파일) 플래그멘테이션이라고도 불리며, 관련 파일간에 참조의 인접성이 없는 것을 의미합니다(자세한 것은, 파일시퀀스를 참조해 주세요).앞의 두 가지 유형의 플래그멘테이션과는 달리 파일 분산은 특정 애플리케이션의 액세스 패턴에 따라 크게 달라지기 때문에 훨씬 더 애매한 개념입니다.이것은 또한 객관적으로 측정하거나 추정하는 것을 매우 어렵게 만든다.단, 가장 자주 액세스하는 [4]파일이 초당 사용 가능한 디스크 스루풋에 비해 작은 경향이 있다는 연구 결과가 나왔기 때문에 플래그멘테이션의 가장 중요한 유형입니다.

관련 파일 조각화를 방지하고 참조 인접성(이 경우 파일 인접성)을 개선하려면 응용 프로그램 작동에 대한 가정이나 능동적 관찰을 수행해야 합니다.작은 파일을 1개의 디렉토리내에 함께 보관해 두고, 그것들을 자연스러운 파일 시스템 순서로 배치하는 것이 가치가 있다고 하는 매우 빈번한 전제가 있습니다.이것은 합리적인 가정인 경우가 많지만 항상 유효한 것은 아닙니다.예를 들어, 응용 프로그램은 여러 개의 서로 다른 파일을 읽을 수 있으며, 아마도 서로 다른 디렉터리에 있는 파일을 정확히 동일한 순서로 읽을 수 있습니다.따라서 단순히 모든 쓰기를 순서대로 정렬하는 파일 시스템이 주어진 애플리케이션에서 더 빨리 작동할 수 있습니다.

부정적인 결과

일반적으로 파일 시스템이 [5]배치되는 순차적 액세스 속도와 회전 지연 시간(및 검색 시간 단축)의 차이가 커지기 때문에 일반 사용자용 하드 디스크 드라이브에서는 파일 시스템 단편화가 더 문제가 됩니다.따라서 fragment화는 파일 시스템 조사 및 설계에서 중요한 문제입니다.fragmentation의 격납은 파일 시스템의 온디스크 형식뿐만 아니라 그 [6]실장에 의해서도 크게 좌우됩니다.파일 시스템 단편화는 기계적인 [7]탐색 시간이 필요하지 않으므로 솔리드 스테이트 드라이브의 성능에 미치는 영향이 적습니다.그러나 파일 시스템은 파일의 비연속적인 각 부분에 대해 추가 메타데이터를 저장해야 합니다.메타데이터의 각 부분 자체가 공간을 차지하기 때문에 처리 능력과 프로세서 시간이 필요합니다.최대 플래그멘테이션 제한에 도달하면 쓰기 요청이 실패합니다.[7]

단순한 파일 시스템 벤치마크에서는 현실적인 노후화와 단편화를 모델링하기 어렵기 때문에 단편화 요소가 생략되는 경우가 많습니다.비교를 쉽게 하기 위해 파일 시스템 벤치마크는 빈 파일 시스템에서 실행되는 경우가 많습니다.따라서 실제 접근 [8]패턴과는 결과가 크게 다를 수 있습니다.

경감

파편화와 싸우기 위해 몇 가지 기술이 개발되었습니다.그것들은 보통 선제적 범주와 소급적 범주로 분류될 수 있다.액세스 패턴을 예측하는 것이 어렵기 때문에 이러한 기술은 대부분 경험적 접근이며 예기치 않은 워크로드에서 성능을 저하시킬 수 있습니다.

플래그멘테이션 방지

프리엠프티브테크놀로지에서는 디스크에 데이터를 쓸 때 플래그멘테이션을 최소한으로 유지하려고 합니다.가장 간단한 방법은 새로운 블록을 새로운 fragment에 할당하는 것이 아니라 가능하면 기존 fragment에 데이터를 추가하는 것입니다.

오늘날 많은 파일 시스템은 익스텐트라고 불리는 다른 여유 공간 조각의 더 긴 청크 또는 청크를 능동적으로 추가된 파일에 미리 할당하려고 시도합니다.이렇게 하면 여러 파일이 동시에 추가될 때 파일 조각화가 방지되므로 파일이 과도하게 [6]얽히는 것을 방지할 수 있습니다.

수정 대상 파일의 최종 크기를 알고 있는 경우 파일 전체를 위한 저장소가 미리 할당될 수 있습니다.예를 들어, Microsoft Windows 의 스왑 파일(페이지 파일)은 통상의 조작으로 동적으로 사이즈를 변경할 수 있기 때문에, 매우 fragment화 될 가능성이 있습니다.이 문제를 방지하려면 페이지 파일을 최소 및 최대 크기로 지정하여 파일 전체를 효과적으로 사전 할당할 수 있습니다.

BitTorrent 및 기타 피어 투 피어 파일 공유 응용 프로그램은 다운로드를 [9]시작할 때 파일에 필요한 전체 공간을 미리 할당하여 플래그멘테이션을 제한합니다.

비교적 최근의 기술은 XFS, HFS+[10] 및 ZFS에서의 지연 할당입니다.reiser4 및 ext4에서는 같은 기술을 allocate-on-flush라고도 부릅니다.파일 시스템이 기록될 때 파일 시스템 블록은 예약되지만 특정 파일의 위치는 아직 정해지지 않았습니다.나중에 메모리 압력이나 트랜잭션 커밋의 결과로 파일 시스템이 강제로 변경 내용을 플러시하면 할당자가 파일 특성을 훨씬 더 잘 알게 됩니다.이 방식을 사용하는 대부분의 파일 시스템은 단일 디렉토리의 파일을 연속적으로 플러시하려고 합니다.단일 디렉토리에서 여러 개의 읽기가 일반적이라고 가정하면 참조 인접성이 [11]향상됩니다.또한 Reiser4는 디렉토리 해시 테이블에 따라 파일 레이아웃을 정렬하기 때문에 파일이 (readdir에 의해 지시된) 자연스러운 파일 시스템 순서로 접근될 때 항상 순차적으로 [12]읽힌다.

조각 모음

주요 기사:조각 모음

소급 기법은 단편화 발생 후 단편화 또는 단편화의 부정적인 영향을 줄이려고 시도한다.많은 파일 시스템은 파일의 fragment를 재정렬하는 디플러그 툴을 제공하고 있습니다.또, 디렉토리나 디렉토리 트리의 작은 파일, 또는 디스크상의 서로 가까운 파일 시퀀스를 보관하는 것으로, 파일의 산란(즉, 그 인접성이나 참조의 인접성을 향상시킵니다)을 줄일 수도 있습니다.

HFS Plus 파일 시스템은 파일을 [13]열 때 크기가 20MiB 미만이고 8개 이상의 조각으로 분할된 파일을 투명하게 조각 모음합니다.

현재는 사용되지 않게 된 Commodore Amiga Smart File System(SFS)은 파일 시스템 사용 중에 자동으로 조각 모음을 수행했습니다.조각 모음 프로세스는 거의 완전히 상태 비저장 상태(작업 중인 위치와는 별개)이므로 즉시 중지하고 시작할 수 있습니다.조각 모음 중에는 메타데이터와 일반 데이터 모두에 대해 데이터 무결성이 보장됩니다.

「 」를 참조해 주세요.

메모들

  1. ^ NTFS 및 ext2+와 같은 일부 파일 시스템은 특수한 목적으로 비어 있는 인접 영역을 미리 할당할 수 있습니다.
  2. ^ 삭제된 파일이 차지하는 공간을 대부분 방해하지 않고 그대로 두는 것이 삭제 취소 프로그램이 작동할 수 있었던 이유입니다. 삭제 취소 프로그램은 디렉토리에서 이름이 삭제되었지만 내용이 디스크에 남아 있는 파일을 복구하기만 하면 됩니다.

레퍼런스

  1. ^ Fisher, Ryan (2022-02-11). "Should I defrag my SSD?". PC Gamer. Archived from the original on 2022-02-18. Retrieved 2022-04-26.
  2. ^ http://www.8bs.com/hints/083.txt - 를 확장할 수 없습니다.에러 설명
  3. ^ http://8bs.com/mag/1to4/basegd1.txt - Cannot extend(확장할 수 없음) 오류로 인한 데이터 손실 가능성
  4. ^ Douceur, John R.; Bolosky, William J. (June 1999). "A Large-Scale Study of File-System Contents". ACM SIGMETRICS Performance Evaluation Review. 27 (1): 59–70. doi:10.1145/301464.301480.
  5. ^ Kryder, Mark H. (2006-04-03). Future Storage Technologies: A Look Beyond the Horizon (PDF). Storage Networking World conference. Seagate Technology. Archived from the original (PDF) on 17 July 2006.
  6. ^ a b McVoy, L. W.; Kleiman, S. R. (Winter 1991). "Extent-like Performance from a UNIX File System" (PostScript). Proceedings of USENIX winter '91. Dallas, Texas: Sun Microsystems, Inc. pp. 33–43. Retrieved 2006-12-14.
  7. ^ a b Hanselman, Scott (3 December 2014). "The real and complete story - Does Windows defragment your SSD?". Scott Hanselman's blog.
  8. ^ Smith, Keith Arnold (January 2001). "Workload-Specific File System Benchmarks" (PDF). Cambridge, Massachusetts: Harvard University. Archived from the original (PDF) on 2004-11-17. Retrieved 2006-12-14. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  9. ^ Layton, Jeffrey (29 March 2009). "From ext3 to ext4: An Interview with Theodore Ts'o". Linux Magazine. QuinStreet.
  10. ^ Singh, Amit (May 2004). "Fragmentation in HFS Plus Volumes". Mac OS X Internals. Archived from the original on 2012-11-18. Retrieved 2009-10-27.
  11. ^ Sweeney, Adam; Doucette, Doug; Hu, Wei; Anderson, Curtis; Nishimoto, Mike; Peck, Geoff (January 1996). "Scalability in the XFS File System" (PDF). Proceedings of the USENIX 1996 Annual Technical Conference. San Diego, California: Silicon Graphics. Retrieved 2006-12-14.
  12. ^ Reiser, Hans (2006-02-06). "The Reiser4 Filesystem". Google TechTalks. Archived from the original on 19 May 2011. Retrieved 2006-12-14.
  13. ^ Singh, Amit (2007). "12 The HFS Plus File System". Mac OS X Internals: A Systems Approach. Addison Wesley. ISBN 0321278542.

추가 정보