그림으로 보는 '애플 파일 시스템(APFS)'의 주요 장점과 볼륨 생성 방법

2016.07.06 19:05    작성자: ONE™

※ 이 글은 <애플의 새로운 파일 시스템, APFS의 모든 것>에 엮인 글입니다.

6월 13일에 개최된 WWDC 16에서 애플은 새로운 '애플 파일 시스템(Apple File System)', 줄여서 'APFS'를 깜짝 공개한 바 있습니다. APFS는 30년 가까이 맥 운영체제의 파일 시스템이었던 HFS+를 대체할 차세대 파일 시스템으로, macOS뿐 아니라 iOS와 watchOS, tvOS 등 애플의 모든 운영체제에서 광범위하게 쓰일 예정입니다.

앞서 백투더맥 필진인 이진협 님이 APFS가 등장하게 된 배경과 특징을 상세하게 풀어주는 장문의 포스트를 게재했는데요. 일반 독자들이 접하기 어려운 기술적인 원리를 친절하고 자세히 알려줌으로써 전문성과 대중성을 겸비하지 않았나 싶습니다.

그런데 설명만 들어서는 확실히 감이 잘 오지 않는 분도 계실 것 같아 사진과 짧은 설명으로 사용자가 당장 체험할 수 있는 장점을 소개해 드리려 합니다.

파티션? 이젠 APFS의 볼륨 : Space Sharing

"...기존의 파티션에서는 한 파티션에 남는 공간이 있고 다른 파티션이 가득 차 있더라도 용량을 즉각 조정하기 어려웠다. 이런 문제를 해결하기 위해 APFS은 공간 공유(Space Sharing)이라는 기법을 사용한다. 볼륨에 여유 공간이 부족해지면 각 볼륨은 별도의 파티션 없이 자신의 크기를 늘이고 그래도 부족할 경우 다른 볼륨이 차지하는 여유공간 역시 받아올 수 있을 정도로 유연하다. 당연히 각 볼륨이 남은 여유 공간을 보고하는 방식 역시 이전과 확연히 달라졌다."

- 애플의 새로운 파일 시스템, APFS의 모든 것

위의 스크린샷이 이러한 원리를 잘 나타내고 있습니다.

스크린샷은 전체 용량이 2TB인 외장 디스크에 APFS 컨테이너를 만들고, 그 안에 test1과 test2라는 이름으로 APFS 볼륨 2개를 생성했을 때의 저장 공간 정보입니다. 볼륨을 생성할 때 용량을 지정할 수도 있지만, 그렇지 않은 경우 위 사진과 같이 볼륨이 컨테이너의 용량을 모두 활용하며, 볼륨이 하나 이상인 경우 컨테이너 전체 용량을 공유하는 것을 볼 수 있습니다.

당연히 전체 공간뿐 아니라 여유 공간도 두 볼륨 사이에 연동됩니다.

예를 들어, 위 스크린샷과 같이 test1 볼륨에 10GB 가량의 파일을 저장하면 test1 볼륨의 여유 공간뿐 아니라 텅 빈 test2 볼륨의 여유 공간까지 같이 줄어듭니다. (위 그림) 두 볼륨이 공유하는 컨테이너의 여유 공간이 test 1 볼륨에 있는 파일에 의해 줄어들기 때문입니다. 즉, 이전과 다르게 볼륨(파티션)을 생성할 때 용량을 얼마나 할당할 것인지 크게 신경 쓸 필요가 없어졌다고 할 수 있습니다. 물론 필요나 목적에 따라 APFS 볼륨을 생성하는 단계에서 최종 용량을 미리 할당하는 것도 가능합니다.

복제본을 다루는 APFS의 방식 : Cloning Files & Directories

"APFS 파일 시스템은 'Copy-On-Write' 방식으로 작동한다. 파일 복사 명령이 내려졌을 때 그 파일을 실제로 복사하지 않는다. 하지만 사용자가 보기에는 그 파일이 복제된 것으로 나타난다. 실제 쓰기 동작은 그 복제된 파일에 수정이 일어난 시점에서 발생한다. 단지 파일이 복제되기만 했을 시점에는 당연히 원본 파일과 복제본 파일의 내용에 아무런 차이가 없기 때문에 이런 방식은 논리적으로 아무런 문제가 없다...

...이는 성능상에서 이득을 줄 뿐만 아니라 쓰기 동작을 줄임으로써 플래시 메모리 기반의 저장장치의 단점을 파일 시스템 단위에서 보정해 줄 수 있을 것이다."

위의 움직이는 그림은 APFS 볼륨에서 용량이 5GB인 파일을 복사하는 모습입니다.

실제로 복사가 이뤄지는 것이 아니라 겉으로만 복제본이 생성된 것처럼 보이는 방식이므로 아무리 복제본을 많이 만들어도 추가적인 공간을 거의 차지하지 않습니다. APFS가 아니라 HFS+나 NTFS 같은 파일 시스템이었다면 원본 1개와 복제본 7개가 40GB를 차지했을 텐데 APFS에서는 5GB에서 불과 몇백KB 밖에 늘지 않습니다. 더불어 복사하는 파일의 용량이 아무리 크더라도 순간적으로 복제본이 생성되는 것을 볼 수 있습니다. 기존의 HFS+ 방식으로 포맷한 드라이브에선 같은 용량의 파일을 복사하는 데 몇 분은 족히 걸린다는 걸 떠올리면 실로 엄청난 변화라고 할 수 있습니다.

아울러 여러 폴더에 동일한 파일이 저장되어 있거나, 실수나 착오로 인터넷에서 다운로드한 파일을 다시 내려받는 경우가 있는데, 용량을 추가로 차지하지 않으므로 중복 파일을 삭제할 필요가 크게 줄어들 것으로 보입니다. 또 중복 파일 삭제 프로그램과도 안녕을 고하게 될 지도 모르겠습니다.

"(복제본의) 내용은 새로 복제된 디스크의 어딘가를 가리키는 것이 아니라 기존의 파일을 그대로 지정하고 있을 것이다. 이 때 파일의 일부가 수정되면 'Copy-on-Write' 정책에 따라 디스크의 빈 공간에 복제본을 기록할 것이다. 이 때 Cloning files and directories 기능이 작동할 경우, 전체 복제본이 디스크에 기록되는 것이 아니라 수정된 파일만 디스크에 기록되고 (수정되지 않은 나머지 복제본은) 여전히 기존의 파일 데이터를 가리키고 있을 것이다."

이것도 예시로 살펴보겠습니다. APFS로 구성한 'test1' 볼륨에 60MB짜리 문서 파일이 저장되어 있습니다. ▼

그리고 이 문서를 복사해 4개의 복제본을 만들었습니다. 원본뿐 아니라 모든 복제본이 저장장치의 특정 데이터 블록을 가리키는 '껍데기'일 뿐이므로 복제본을 여러 개 만든다고 해서 여유 공간을 추가로 점유하지 않습니다. ▼

그러다 4개의 복제본 가운데 하나를 수정하면, 해당 복제본에 해당하는 용량(60M) 만큼 저장장치의 여유 공간이 줄어듭니다. (나머지 복제본은 아무런 수정이 가해지지 않았고 여전히 원본과 동일한 상태입니다.) 복제본을 편집할 때만 '실제로' 복사가 이뤄지므로 파일을 디스크에 쓰는 빈도가 감소하면서 성능 저하를 최소화할 수 있고, 여유 공간 확보에도 도움이 되니 그야말로 1석 2조입니다. ▼

더 이상 기다림은 그만 : Fast Directory Sizing

빠른 디렉토리 용량 산정 기능은 그림만 봐도 바로 이해가 되실 겁니다.


* HFS+ 파일 시스템에서 폴더의 용량을 계산하는 모습

"현재의 HFS+ 파일 시스템은 사용자가 용량을 원할 때마다 용량을 새로 계산한다. 따라서 복잡한 계층 구조를 가진 디렉토리의 경우 계층별로 접근해 그 용량을 계산해 나와야 하기 때문에 최종 용량 계산까지 긴 시간이 소요된다. (위 그림)"


* APFS 파일 시스템에서 폴더의 용량을 계산하는 모습

"하지만 APFS 볼륨에선 각 디렉토리가 용량 정보를 항상 기록하고 있다. 즉, 사용자가 그 디렉토리의 용량을 요구하면 새로 용량을 계산하는 것이 아니라 자신이 갖고 있는 용량 정보를 보여주기만 하는 것이다. 당연히 훨씬 빠르고, 용량을 여러 번 확인하는 경우 전체 컴퓨터가 계산하는 정보를 줄일 수 있는 이점을 가지고 있다. (위 그림)"

덧붙이는 말

지금까지 사용자가 APFS을 통해 누릴 수 있는 성능 상의 몇 가지 장점을 살펴봤습니다.

이 외에도 APFS는 타임머신에서 사용하는 하드 링크보다 훨씬 진보된 '스냅샷' 기능을 제공하며, 파일을 삭제하거나 여유 공간을 사용할 때만 데이터 블록을 정리하는 비동기 TRIM, 3가지 유형의 강력한 암호화 기능, 정전이나 오류으로 데이터 손상을 막는 고유한 파일 보호 체계를 갖추고 있습니다. 64비트 기반의 아이노드나 나노초 단위로 기록되는 타임스탬프 같은 기능은 당장은 실효성이 떨어지더라도 먼 미래를 미리 준비하는 차원에서 바라보면 될 듯합니다.

무엇보다 중요한 건 APFS가 언제 정식으로 지원되는지 여부일 텐데요. APFS는 올가을에 출시될 macOS 시에라부터 부분적으로 지원될 예정이며 차기 운영체제나 차차기 운영체제에서 확실히 자리잡을 예정입니다. 하지만 당장 지금도 macOS 시에라 개발자 프리뷰 버전을 통해 APFS 볼륨을 구성해 볼 수 있습니다.

어디까지나 개발이 한창 진행 중인 파일 시스템이라 아직까지 안정성이 떨어지고 애플이 발표한 내용 가운데 아직 구현되지 않은 기능도 많이 남아 있습니다. 특히 시동 디스크로 사용할 수 없어서 운영체제를 설치하지 못하며, SSD와 HDD가 하나로 묶인 퓨전드라이브에서 APFS 볼륨을 구성하는 것도 불가능합니다. 또 APFS 볼륨은 타임머신 백업 드라이브로도 아직은 이용할 수 없습니다.

따라서 일상적인 용도로 APFS를 활용하기에는 무리가 있고, 특히 중요한 파일을 저장하는 용도로는 전혀 적합하지 않습니다. 애플에 따르면 앞으로 1년 가량 테스트를 진행할 예정이라고 하는데요. 나중에 HFS+를 바로 대체하게 될지, 아니면 선택사항으로 제공할지 정해지지 않았고, 시에라 베타 버전에서 생성한 APFS 볼륨을 차후에 나올 정식 버전에서 그대로 사용할 수 있을지 여부도 아직은 불분명합니다. 테스트가 진행됨에 따라 점차 신뢰성을 키우고 부족한 부분을 다듬어 나가겠지만, 지금은 말 그대로 '맛보기' 수준입니다.

APFS를 미리 체험해 보실 분은 이 같은 부분을 충분히 숙지하시기 바랍니다.

아래는 macOS 시에라 베타 버전에서 APFS 볼륨을 생성하는 방법입니다. 아직 APFS를 생성하고 관리하는 UI가 준비되지 않아서 터미널 명령어를 사용해야 하는데요. macOS 시에라 정식 버전에선 다른 파일 시스템(HFS+, FAT32...)과 마찬가지로 '디스크 유틸리티'를 통해 APFS 볼륨을 생성하고 관리할 수 있을 것으로 예상됩니다.

macOS Sierra에서 APFS 볼륨 생성하기

1. 응용 프로그램 > 유틸리티 폴더에 있는 '터미널'을 실행합니다.

2. 터미널에 'diskutil list' 명령어를 입력하면 맥에 설치되거나 연결된 모든 저장장치 정보가 표시됩니다. (사용자 환경에 따라 볼륨 분할 상태나 디스크 번호 등의 일부 정보가 다르게 나타날 수 있습니다.) 예시에선 USB 외장 드라이브에 APFS 볼륨을 구성해 볼 텐데요. 제 환경에선 USB 외장 드라이브의 식별자는 'disk3'입니다. ▼

3. USB 외장 드라이브에 'test1'이라는 이름을 가진 첫 번째 APFS 볼륨을 만들어 보겠습니다. 터미널에 다음과 같이 명령어를 입력하면 Apple_APFS 유형의 새로운 볼륨이 생성됩니다. ▼

diskutil partitionDisk disk3 gpt apfs test1 0b

4. 이제 다음과 같은 명령어를 입력하면 APFS 컨테이너(disk3s2) 안에 APFS 볼륨(disk3s2s1)이 생성된 것을 볼 수 있습니다. (이전 포스트를 읽으신 분은 컨테이너와 볼륨의 차이를 잘 알고 계실 겁니다. APFS는 컨테이너라는 '용기' 안에 여러 개의 볼륨이 생성되는 구조를 가지고 있습니다.) ▼

diskutil apfs list

5. 필수는 아니지만 '공간 공유(Space Sharing)'를 테스트해 보실 분은 APFS 볼륨을 하나 더 생성하세요. 첫 번째 볼륨과 마찬가지로 용량을 미리 지정하지 않으셔도 됩니다. ▼

diskutil apfs addvolume disk3s2 apfs test2

6. 4번째 단계에서 사용한 명령어를 다시 입력하면 기존에 생성한 APFS 볼륨(disk3s2s1) 밑에 두 번째 APFS 볼륨(disk3s2s2)이 표시되는 것을 볼 수 있습니다. ▼

* 참고로 diskutil apfs 명령어를 입력하면 디스크 목록 보기를 비롯해 볼륨 및 컨테이너 추가∙삭제 기능을 수행할 수 있는 옵션을 확인하실 수 있습니다. ▼

7. 이제 생성한 볼륨들을 Finder에서 다룰 수 있도록 볼륨을 시스템에 마운트할 차례입니다. 

참고로 macOS 시에라 개발자 프리뷰에선 AFPS 볼륨이 자동으로 마운트 되지 않는 버그가 있습니다. DP2에선 버그가 해결된 것으로 보이는데, DP2에서도 볼륨이 자동 마운트되지 않는다면 아래 명령어를 사용해 볼륨을 직접 마운트하시기 바랍니다. 아래 예시는 APFS 볼륨 2개를 마운트하는 모습입니다. 만약 APFS 볼륨을 하나만 만드셨다면 명령어 역시 한 번만 입력하면 됩니다. (디스크 식별자를 잘 확인하세요.)  ▼

diskutil mount 볼륨_식별자

8. APFS 볼륨이 성공적으로 마운트되면 Finder를 통해 파일을 복사하거나 이동 또는 삭제할 수 있습니다. 이제 위에서 설명한 APFS 파일 시스템의 장점을 직접 체험해 보세요. ▼



참조
애플의 새로운 파일 시스템, APFS의 모든 것
Apple Deveoloper - Apple File System Guide

관련 글
• 애플, 차세대 맥 운영체제 'macOS Sierra' 발표
• 구형 맥에 퓨전 드라이브를 활성화 하는 방법
• 애플, macOS 시에라 2번째 개발자 프리뷰(DP2) 배포... 알려진 문제와 버그 내역

저작자 표시 비영리 변경 금지
신고
    
  1. Blog Icon
    leesy86@naver.com

    정말 대박....

    업무상 같은폴더, 파일을 많이 복사해서 사용하는데...

    획기적으로 용량이 줄어들고 속도도 빨리지겠내요..

    하지만 회사에서는 윈도우를 쓴다는게 함정 ㅠㅠ

  2. 윈도우에는 APFS 에 버금가는 ReFS 라는 차세대 파일시스템이 이미 있습니다. APFS에 없는 thin-provisioning 기능 까지 지원합니다.

  3. Blog Icon
    맥북프로

    APFS도 용어가 조금 다르긴 하지만 씬프로비저닝을 지원합니다.

  4. Blog Icon
    ReFS

    APFS는 어떤 용어를 사용하나요? 알려주시면 고맙겠습니다. APFS가 thin-provisioning 을 지원한다면 CoreStorage 까지 버려지는거군요

  5. Blog Icon
    Jason

    Space Sharing 이라고 본문에 있네요..

  6. Blog Icon
    ReFS

    Space sharing 은 그냥 디스크 내의 남는공간 같이쓰는거 아닌가요?
    Thin provisioning 은 스토리지를 가상화하여 물리적인 공간에 구애받지 않는 볼륨을 만드는것이 목적입니다. 둘은 큰 관련이 없어보이는데요

  7. Blog Icon
    Jason

    Front-end에서 포장을 달리했을뿐 Back-end에서 보면 같은 내용입니다..

  8. Blog Icon
    맥북프로

    APFS의 Space Sharing이나 Thin Provisioning이나 세부적인 방법은 각기 다르겠죠. 그래도 본질은 실제 물리 용량을 속여서 자원/비용을 줄이고, 보조저장장치와 파티션 관리에 들이는 노력을 줄일 수 있다는 점에서 충분히 동일선상에서 다룰 수 있을 것 같습니다.

    APFS의 Space Sharing

    “APFS의 볼륨은 파티션을 다시 할 필요 없이 용량을 확장하거나 축소할 수 있다. 즉, 각 볼륨은 기본적으로 할당받은 용량을 차지하고 있지만 현재의 파티션처럼 모든 디스크 공간을 파티션에 할당할 필요는 없다. 볼륨에 여유 공간이 부족해지면 각 볼륨은 별도의 파티션 없이 자신의 크기를 늘이고 그래도 부족할 경우 다른 볼륨이 차지하는 여유 공간 역시 받아올 수 있을 정도로 유연하다.”

    “대규모 저장장치를 구성할 때 필요한 블럭을 우선 할당하고 그 쪽에만 파일시스템을 구축하여 즉시 사용가능하도록 할 수 있다.(대용량의 저장장치가 포맷이 끝나지 않았더라도 필요한 지점부터 포맷하고 파일시스템을 구축하여 전체 저장장치의 포맷이 진행되는 중에도 디스크를 사용할 수 있음) 만약 물리적인 용량이 부족하면 추가 저장장치를 연결할 수 있다.“


    Thin Provisioning

    “물리적 스토리지 풀에 실제 존재하는 것보다 더 많은 논리적 스토리지를 호스트 또는 사용자에게 제공할 수 있도록 설계할 수 있다. 6명의 사용자가 있고 만약 한 사용자마다 실제로 6TB씩의 물리 저장소를 배정한다면 24TB의 저장공간이 필요하다. 하지만 사용자들이 각 1TB의 용량만을 사용했다면 총 4TB의 용량을 사용한 것이다. 이렇게 되면 20TB의 용량 낭비와 장비공간 낭비, 전력 낭비가 생기게 된다. 결과적으로 비용은 비용대로 많이 소요되고 서비스 다운타임 또한 발생하는 문제점을 가지고 있다.

    “Thin Provisioning 기법을 사용하여 스토리지에 남아도는 용량 없이 꼭 필요한 만큼, 필요한 때 사용할 수 있도록 스토리지를 날씬(Thin)하게 만들 수 있게 되었다. Thin Provisioning은 공간을 미리 할당하는 대신 데이터가 기록될 때 각 볼륨에 동적으로 스토리지 공간이 할당된다. 즉 스토리지 용량을 애플리케이션이 당장 필요로 하는 수준으로 제한(물리적 공간 할당)하되 마치 사용자는 많은 공간(가상 할당)을 사용 하고 있는 것처럼 보여준다. 그러다가 실질적인 용량 추가 요청이 있을 시 조금씩 용량을 늘려주게 됨으로써 스토리지 활용률을 높이는 것이다.”

  9. Blog Icon
    ?

    ReFS님// "스토리지를 가상화하여 물리적인 공간에 구애받지 않는 볼륨을 만드는 것"
    Space Sharing과 다를게 없는데요? 본인이 말하면서도 눈치 못채시는듯...

  10. Space Sharing 은 단일 디스크 (한개의 물리적 볼륨) 내에서만 공유됩니다. 공식 문서를 봐도 RAID 의 Concatenation 기능이 필요하면 Apple software RAID 를 이용하라고 되어있습니다. 해당 기능뿐만 아니라 RAID의 disk redundancy 기능또한 필수입니다. 하지만 APFS 에는 스토리지 풀 (물리적 볼륨) 기능이 없습니다. 때문에 Space sharing 과 thin provisioning 은 전혀다른 것 이라고 말하는 겁니다. (전자는 논리적 볼륨 레벨, 후자는 물리적 볼륨/스토리지 풀 레벨입니다)

    아래 URL 을 읽어보시죠
    https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/GeneralCharacteristics/GeneralCharacteristics.html#//apple_ref/doc/uid/TP40016999-CH2-SW1

    그리고 맥북프로님이 말씀하시는 내용의 출처는 어디인가요?

  11. Blog Icon
    겅덩이

    와;;;; 파일 시스템에 드디어 혁신이 불어오네요ㅎㅎㅎㅎ
    항상 용량볼때 기다릴때 정말 힘들었는데;;

  12. Blog Icon
    ㅉㅉ

    윈도우는 원드라이브로 윈도우 8때 부터 있던 기능이 이제야.. 혁신은 아니라.. 뒷북이라 하죠 ㅋㅋ

  13. Blog Icon
    최창흠

    특정 파일을 여러개 복사해도 복사본들은 원본만 가리키는 그림자일뿐이라면,

    만약 원본만 지울 경우(완전히 휴지통 비우기까지 완료한 상태)는 어떻게 되는 걸까요.
    이런 경우는 나머지 복사본들 중에서 하나의 파일에 모든 정보를 전해주고(용량을 넘겨주고) 자신은 사라지는 것일까요?

  14. 쉽게 설명하기 위해 '원본'이라는 용어를 사용했는데 모든 파일이 하나의 데이터 블록을 가리키고 있다는 표현이 더 적절할 것 같습니다. 따라서 말씀하신대로 원본을 지우더라도 나머지 파일에는 영향을 끼치지 않습니다.

  15. Blog Icon
    헤도니스

    확실히 아는건 아니지만 말씀하신대로 될것같네요

    여러모로 획기적인 시스템이군요

  16. 복사본을 수정하는 시점에 쓰기가 이루어진다면 원본을 수정할경우 어떤식으로 동작할지가 궁금하네요.

  17. 위에 단 댓글과 같은 맥락이 아닐까 싶은데요. 원본을 복제하면 원본과 복제본이 모두 같은 데이터 블록을 가리킵니다. 원본과 복제본이 사실상 '동급' 파일로 취급되는 셈이죠. 이후 원본을 수정하거나 편집하는 즉시 새로운 데이터 블록이 생성되면서 나머지 복제본과는 다른 데이터 블록을 가르키게 됩니다. 그리고 원본의 복제본은 원본이 수정되기 전의 내용을 그대로 간직하게 되겠죠.

  18. Blog Icon
    syong0921

    그렇다면 원본 자료는 따로 보관이 되고 (파티션에 속하지 않고) 우리가 접근하는곳에 심볼릭 링크를 심는 느낌인건가요?

    자료의 완전한 삭제는 모든 심볼릭 링크가 제거 되었을 때 원본 자료가 삭제가 되고, 심볼릭 링크가 남아 있는 경우 원본을 살려두고요.

    이렇게 이해하는것이 맞게 이해한것인가요?

  19. Blog Icon
    Claude

    예- 원본이라는 '표현'과 '파티션에 속하지 않고'라는 말만 빼고 본다면, 원리 자체는 정확히 이해하고 계십니다. 파티션에 저장되는 건 맞습니다 ㅎㅎ
    우리가 원본이라고 생각하는 파일 자체도 원래 심볼릭 링크에 불과합니다. 그래서 '복사한다'라는 의미는 단지 '또다른 심볼릭 링크를 생성한다'는 의미죠. 말씀하신대로 완전한 삭제는, 해당 자료를 가리키는 링크들이 완전히 삭제되었을 때가 맞습니다. (APFS에 따르면 그때, 메모리를 초기화한다고 하죠)

  20. Blog Icon
    금연토끼

    APFS 파티션은 2017년중에 업데이트 할꺼 같다고 하던데요...
    가을에 있을 시에라랑 같이 업데이트는 안될꺼 같은데 들리는 소리가 그렇습니다.
    파티션 교체는 상당한 테스트 기간이 필요로 하기 때문에 아마도 2017년 초쯤 될꺼 같네요...
    현제 볼때는 참 좋은 파티션인데요....

  21. 네. 말씀하신 것처럼 WWDC 세션 자료를 보니 단순히 2017년에 도입된다는 내용만 있더군요.
    다음 운영체제 출시 예정일이 내년 10월쯤 될 테니 빠르면 macOS 시에라에서도 만나볼 수 있을 것 같습니다. 아니면 본문에 적은 것처럼 시에라 다음에 나올 운영체제와 같이 찾아올 수 있겠구요.

  22. Blog Icon
    sdsd

    스냅샷기능이 궁금하네요
    어떤 효용성이 있을지..

  23. 저도 참 궁금한 기능인데 당장 테스트해 볼 방법이 없어서
    일단은 관망만 하고 있습니다.

  24. Blog Icon
    스톤콜드

    역시... 이 기능들은 이미 btrfs 에 대부분있는 기능입니다.
    단 CoW 기능을 DB와 같이 계속 쓰는데는 아주 부적합합니다.
    Snapshot도 btrfs와 거의 비슷할것 같은데... btrfs의 스냡샷 기능으로 timemachine 흉내내기를 봤는데 이게 다시 맥에서 나오니 신기하네요.

  25. Blog Icon
    여화

    APFS가 어쨌거나 나는 사파리를 떠났다.

  26. 좋은 정보 감사합니다.

    이해가 쉽도록 ONE님은 원본과 복사본이라는 단어를 선택하셨지만 실제로는
    진짜 원본은 하드디스크에 숨겨진 상태로 원본이라고 느껴지는 링크만 존재할 뿐이죠.

    (가르키다가 아닌 가리키다입니다...)

  27. 지적하신 오타는 슬쩍 수정했습니다.
    감사합니다 :-)

  28. 이게 좋은 건 알겠는데...
    데이터를 전부 유지하고 apfs로 업그레이드 하는건 안되겠죠?ㅠㅠ

  29. Blog Icon
    n

    흥미롭네요.
    하지만 역시 NTFS랑은 호환이 안 되겠죠...?

  30. Blog Icon
    ㅁㄴㅇㅁㄴㅇ

    APFS는 윈도우에서 쓰기는 당연히 안되겠지만 읽기는 가능한가요?