Google이 FUSE를 대체하는 SDCardFS와 이를 구현하여 I/O 오버헤드를 줄이는 방법에 대한 심층 탐구입니다.
몇 달 전 Google은 'SDCardFS” Linux 커널의 공식 AOSP 브랜치로 이동합니다. 당시 움직임은 오직 일부 커널 개발자, 그러나 그렇지 않으면 대부분의 사용자의 레이더 아래로 날아갔습니다. 나를 포함한 대부분의 사용자가 Android OS와 커널 내부에서 무슨 일이 벌어지고 있는지 전혀 모른다는 사실을 고려하면 놀랄 일도 아닙니다.
그러나 가장 최근 에피소드는 Android 개발자 백스테이지 팟캐스트는 이 주제에 대한 관심을 다시 불러일으켰습니다. Chet Haase(Google의 수석 소프트웨어 엔지니어)가 진행하는 팟캐스트에서는 커널에 대한 최근 및 향후 변경 사항을 살펴보았습니다. 이 쇼에는 Android 팀에서 일하는 Linux 커널 개발자인 Rom Lemarchand가 있었습니다. 듀오는 주로 A/B 업데이트를 수용하기 위해 어떤 변경 사항이 적용되었는지 논의했지만, 에피소드의 마지막 5분 동안 Lemarchand 씨는 그의 팀이 작업하고 있는 "차세대 큰 일"에 대해 이야기했습니다. SDCardFS.
나는 이 팟캐스트를 듣고 나서 SDCardFS의 존재에 대해 알게 되었음을 인정해야 합니다. 물론 이 주제에 관심을 가진 사람은 나뿐만이 아니었습니다. 최근 Reddit 스레드 보여 주었다. 하지만 팟캐스트에서 제공하는 기본적인 설명에는 만족하지 못하고, 일부 오해를 해소하려는 노력의 일환으로 잘못된 정보가 널리 퍼져 있기 때문에 저는 스스로 조사를 하고 관련 지식을 가진 몇몇 전문가들과 이야기를 나눴습니다. 문제.
이 기사에 대한 지식을 제공하고 시간을 내어 내 질문에 답변해 준 소프트웨어 개발자 Michal Kowalczyk에게 깊은 감사를 드립니다.
"외부"는 실제로 내부입니다
즉시, 우리가 정리해야 할 몇 가지 오해가 있을 것입니다. 그렇지 않으면 기사의 나머지 부분이 매우 혼란스러울 것입니다. SD 카드와 Android 휴대폰의 역사에 대해 토론하는 것이 도움이 됩니다.
Android 휴대폰 초기에는 거의 모든 기기가 저장을 위해 microSD 카드를 사용했습니다. 이는 당시 휴대폰에 내부 저장 용량이 아주 작았기 때문이었습니다. 그러나 애플리케이션 저장에 사용되는 SD 카드는 적어도 내부 플래시 메모리가 데이터를 읽고 쓸 수 있는 속도에 비해 뛰어난 사용자 경험을 제공하지 못하는 경우가 많습니다. 따라서 외부 데이터 저장을 위한 SD 카드의 사용 증가는 Google의 사용자 경험 문제가 되었습니다.
외부 저장 장치로 SD 카드가 초기에 확산됨에 따라 Android의 저장소 명명 규칙은 모든 장치에 실제 물리적 microSD 카드 슬롯이 있다는 사실을 기반으로 했습니다. 그러나 SD 카드 슬롯이 없는 장치에서도 /sdcard 라벨은 실제 내부 저장 칩을 가리키는 데 여전히 사용되었습니다. 더 혼란스러운 점은 물리적 SD 카드와 저장용 대용량 저장 칩을 모두 활용하는 장치가 SD 카드를 기반으로 파티션 이름을 지정하는 경우가 많다는 사실입니다. 예를 들어, 이러한 장치에서 /sdcard 마운트 지점은 실제 내부 저장 칩을 참조하는 반면, /storage/sdcard1과 같은 마운트 지점은 물리적 외부 카드를 참조합니다.
따라서 microSD 카드가 실질적으로 외부 저장소로 간주됨에도 불구하고 명명 규칙으로 인해 물리적 카드를 실제로 사용하기 훨씬 전부터 "SDCard"가 붙어 있었습니다. 스토리지에 대한 이러한 혼란은 애플리케이션 데이터와 해당 미디어가 두 파티션 사이에 분리되어 있다는 사실로 인해 애플리케이션 개발자에게 약간의 골칫거리이기도 했습니다.
초기 내부 저장 칩의 저장 공간이 부족하여 사용자는 더 이상 애플리케이션을 설치할 수 없다는 사실을 알게 되었습니다(/data 파티션이 가득 차서). 한편, 더 큰 용량의 microSD 카드는 미디어(예: 사진, 음악, 영화)만 담는 것으로 강등되었습니다. 예전에 우리 포럼을 검색한 사용자라면 Link2SD 및 Apps2SD라는 이름을 기억할 것입니다. 이는 사용자가 애플리케이션과 해당 데이터를 모두 물리적 SD 카드에 설치할 수 있게 해주는 (루트) 솔루션이었습니다. 하지만 이는 완벽한 솔루션과는 거리가 멀기 때문에 Google이 개입해야 했습니다.
유명하게도 Google은 아주 일찍부터 SD 카드의 플러그를 뽑았습니다. Nexus One은 microSD 카드 슬롯이 있는 유일한 Nexus 기기로 남아 있습니다(Nexus 브랜드가 사실상 사라진 이후로는 영원히 그럴 것입니다). Nexus S에는 이제 모든 애플리케이션 데이터와 미디어를 저장하는 단일 통합 파티션인 /data 파티션만 있었습니다. 한때 /sdcard 마운트 지점으로 알려졌던 것은 이제 단순히 가상 파일 시스템(아래에서 구현됨)을 참조하는 것입니다. 퓨즈 프로토콜)은 데이터 파티션 - /data/media/0에 있습니다.
호환성을 유지하고 혼란을 줄이기 위해 Google은 여전히 이 가상 "sdcard" 파티션을 사용하여 미디어를 보관했습니다. 그러나 이제 이 "sdcard" 가상 파티션은 실제로 /data 내에 위치하므로 그 안에 저장된 모든 항목은 내부 저장 칩의 저장 공간에 포함됩니다. 따라서 애플리케이션(/data)과 미디어(/data/media)에 할당할 공간의 양을 고려하는 것은 OEM의 몫이었습니다.
Google은 제조업체가 그들의 예를 따라 SD 카드를 제거하기를 바랐습니다. 다행스럽게도 시간이 지남에 따라 휴대폰 제조업체는 비용 효율성을 유지하면서 더 높은 용량의 이러한 구성 요소를 공급할 수 있게 되었고, 이에 따라 SD 카드에 대한 필요성이 줄어들기 시작했습니다. 그러나 개발자와 OEM이 조정해야 하는 노력을 줄이기 위해 명명 규칙이 지속되어 왔습니다. 현재 "외부 저장소"라고 하면 다음을 의미합니다. 둘 중 하나라도: 실제 이동식 microSD 카드 또는 /data/media에 있는 가상 "SDCard" 파티션. 후자는 실질적으로 말해서, 실제로 내부 저장소입니다, 그러나 Google의 명명 규칙은 이 데이터가 사용자가 액세스할 수 있다는 사실(예: 컴퓨터에 연결되어 있는 경우)로 인해 이를 구별합니다.
현재 "외부 저장소"라고 하면 다음을 의미합니다. 둘 중 하나라도: 실제 이동식 microSD 카드 또는 /data/media에 있는 가상 "SDCard" 파티션.
안드로이드 가상 파일 시스템의 역사
이제 "sdcard"는 가상 파일 시스템으로 취급되므로 Google이 원하는 어떤 파일 시스템으로도 포맷할 수 있다는 의미입니다. Nexus S 및 Android 2.3부터 Google은 'sdcard' 형식을 VFAT(가상 FAT)로 선택했습니다. VFAT를 탑재하면 거의 모든 컴퓨터가 휴대폰에 저장된 데이터에 액세스할 수 있기 때문에 이러한 움직임은 당시에는 의미가 있었습니다. 그러나 이 초기 구현에는 두 가지 주요 문제가 있었습니다.
첫 번째는 주로 최종 사용자(귀하)와 관련된 것입니다. 장치를 컴퓨터에 연결하려면 USB 대용량 저장 모드를 사용하여 데이터를 전송해야 합니다. 그러나 이를 위해서는 컴퓨터가 데이터에 액세스하기 전에 Android 장치가 가상 파티션을 마운트 해제해야 했습니다. 사용자가 연결되어 있는 동안 장치를 사용하려는 경우 많은 항목을 사용할 수 없는 것으로 표시됩니다.
그만큼 미디어 전송 프로토콜 도입 (MTP)는 이 첫 번째 문제를 해결했습니다. 연결되면 컴퓨터는 장치를 "미디어 저장소" 장치로 인식합니다. 이는 휴대폰에서 파일 목록을 요청하고 MTP는 컴퓨터가 장치에서 다운로드할 수 있는 파일 목록을 반환합니다. 파일 삭제가 요청되면 MTP는 요청된 파일을 저장소에서 제거하라는 명령을 보냅니다. 실제로 "sdcard"를 마운트하는 USB 대용량 저장 모드와 달리 MTP를 사용하면 사용자가 연결되어 있는 동안 장치를 계속 사용할 수 있습니다. 또한 Android 휴대폰에 있는 파일 시스템은 컴퓨터가 장치의 파일을 인식하는 데 더 이상 중요하지 않습니다.
둘째, VFAT는 Google에 필요한 강력한 권한 관리 기능을 제공하지 않았다는 사실이 있었습니다. 초기에 많은 응용 프로그램 개발자는 "sdcard"를 파일을 저장할 위치에 대한 통일된 감각 없이 응용 프로그램 데이터의 쓰레기장으로 취급했습니다. 많은 애플리케이션은 단순히 앱 이름으로 폴더를 만들고 거기에 파일을 저장합니다.
당시 거의 모든 애플리케이션에는 WRITE_EXTERNAL_STORAGE 애플리케이션 파일을 외부 저장소에 쓸 수 있는 권한입니다. 그러나 더욱 문제가 되는 것은 거의 모든 응용프로그램에 READ_EXTERNAL_STORAGE 권한 - 자신의 데이터 파일을 읽기 위한 것입니다! 이는 애플리케이션이 외부 스토리지의 어느 위치에나 저장된 데이터에 쉽게 액세스할 수 있음을 의미합니다. 이러한 권한은 많은 앱에서 필요하기 때문에 사용자가 부여하는 경우가 많습니다. 기능.
구글은 이를 문제가 있는 것으로 분명히 보았습니다. 권한 관리의 기본 개념은 앱이 액세스할 수 있는 것과 없는 것을 분리하는 것입니다. 거의 모든 앱에 잠재적으로 민감한 사용자 데이터에 대한 읽기 액세스 권한이 부여된다면 해당 권한은 의미가 없습니다. 따라서 Google은 새로운 접근 방식이 필요하다고 결정했습니다. FUSE가 등장하는 곳이 바로 여기입니다.
사용자 공간의 파일 시스템(FUSE)
Android 4.4부터 Google은 더 이상 가상 "sdcard" 파티션을 VFAT로 마운트하지 않기로 결정했습니다. 대신 Google은 FUSE를 사용하여 "sdcard" 가상 파티션에서 FAT32를 에뮬레이트하기 시작했습니다. sdcard 프로그램 호출로 FAT-on-sdcard 스타일 디렉터리 권한을 에뮬레이트하는 FUSE, 애플리케이션이 외부 저장소에 저장된 데이터에 액세스하기 시작할 수 있습니다. 아무런 권한도 필요 없이. 실제로 API 레벨 19부터 READ_EXTERNAL_STORAGE는 다음 위치에 있는 파일에 액세스하는 데 더 이상 필요하지 않습니다. 외부 저장소 - FUSE 데몬이 생성한 데이터 폴더가 앱의 패키지 이름과 일치하는 경우. FUSE가 처리할 것입니다. 외부 저장소에 있는 파일의 소유자, 그룹 및 모드를 종합합니다. 응용 프로그램이 설치되면.
FUSE는 권한이 없는 사용자가 가상 파일 시스템을 작성할 수 있다는 점에서 커널 내 모듈과 다릅니다. Google이 FUSE를 구현한 이유는 다소 간단합니다. FUSE는 원하는 대로 작동했으며 이미 FUSE를 구현했습니다. 잘 이해되고 문서화됨 리눅스의 세계에서. 인용하자면 이 문제에 대한 Google 개발자:
"FUSE는 훌륭하고 안정적인 API이기 때문에 커널 버전 간에 이동할 때 유지 관리 작업이 본질적으로 필요하지 않습니다. 커널 내 솔루션으로 마이그레이션했다면 안정적인 각 커널 버전에 대한 패치 세트를 유지하기 위해 등록하게 될 것입니다." -Jeff Sharkey, Google 소프트웨어 엔지니어
그러나 FUSE의 오버헤드가 다른 문제 중에서도 성능 저하를 초래하고 있다는 것이 점점 분명해졌습니다. 이 문제에 관해 제가 이야기를 나눈 개발자인 Michal Kowalczyk는 다음과 같이 말했습니다. 훌륭한 블로그 게시물을 작성했습니다 1년 전에 FUSE의 현재 문제를 자세히 설명했습니다. 더 많은 기술적인 세부 사항은 그의 블로그에서 읽을 수 있지만, 나는 (그의 허락을 받아) 그의 연구 결과를 좀 더 일반인의 용어로 설명하겠습니다.
FUSE의 문제
Android에서 "sdcard" 사용자 공간 데몬은 FUSE를 활용하여 부팅 시 에뮬레이트된 외부 저장소 디렉터리에 /dev/fuse를 마운트합니다. 그 후, sdcard 데몬은 커널에서 보류 중인 메시지가 있는지 FUSE 장치를 폴링합니다. 팟캐스트를 들으셨다면 Lemarchand씨가 I/O 작업 중에 FUSE가 오버헤드를 도입한다고 언급하는 것을 들어보셨을 것입니다. 기본적으로 발생하는 상황은 다음과 같습니다.
현실 세계에서는 이러한 성능 저하가 영향을 미칩니다. 어느 외부 저장소에 저장된 파일.
문제 #1 - I/O 오버헤드
"test.txt"라는 간단한 텍스트 파일을 만들어 /sdcard/test.txt에 저장한다고 가정해 보겠습니다. 다시 한번 말씀드리지만, 실제로는 현재 사용자가 기본 사용자라고 가정할 때 /data/media/0/test.txt입니다. 장치). 이 파일을 읽으려면(명령 cat) 시스템이 열기, 읽기, 닫기의 3가지 명령을 실행할 것으로 예상됩니다. 실제로 Kowalczyk 씨가 다음을 사용하여 시연한 것처럼 스트레이스, 다음과 같은 일이 발생합니다.
하지만 파일이 sdcard 데몬이 관리하는 외부 저장소에 있기 때문에 수행해야 할 추가 작업이 많이 있습니다. Kowalczyk씨에 따르면 기본적으로 8가지 추가 단계가 필요합니다. 이 3가지 개별 명령 각각:
- 사용자 공간 애플리케이션은 커널의 FUSE 드라이버에 의해 처리될 시스템 호출을 발행합니다(첫 번째 strace 출력에서 볼 수 있음)
- 커널의 FUSE 드라이버는 사용자 공간 데몬(sdcard)에 새 요청에 대해 알립니다.
- 사용자 공간 데몬이 /dev/fuse를 읽습니다.
- 사용자 공간 데몬은 명령을 구문 분석하고 파일 작업을 인식합니다(예: 열려 있는)
- 사용자 공간 데몬은 실제 파일 시스템(EXT4)에 시스템 호출을 발행합니다.
- 커널은 물리적 데이터 액세스를 처리하고 데이터를 사용자 공간으로 다시 보냅니다.
- 사용자 공간은 데이터를 수정하거나 수정하지 않고 /dev/fuse를 통해 다시 커널로 전달합니다.
- 커널은 원래 시스템 호출을 완료하고 데이터를 실제 사용자 공간 애플리케이션으로 이동합니다(예제에서는 cat).
이것은 다음과 같습니다 많이 실행할 단일 I/O 명령에만 오버헤드가 발생합니다. 그리고 당신 말이 맞을 것입니다. 이를 입증하기 위해 Kowalczyk 씨는 두 가지 다른 I/O 테스트를 시도했습니다. 하나는 큰 파일을 복사하는 것과 다른 하나는 많은 작은 파일을 복사하는 것이었습니다. 그는 이러한 작업을 처리하는 FUSE(FAT32로 마운트된 가상 파티션에서)의 속도를 비교했습니다. 커널(EXT4로 포맷된 데이터 파티션)에서 FUSE가 실제로 상당한 기여를 하고 있음을 발견했습니다. 간접비.
첫 번째 테스트에서는 두 가지 테스트 조건에서 725MB 파일을 복사했다. 그는 FUSE 구현이 대용량 파일을 전송한다는 것을 발견했습니다. 17% 더 느리게.
두 번째 테스트에서 그는 각각의 크기가 5KB인 10,000개의 파일을 복사했습니다. 이 시나리오에서는 FUSE 구현이 끝났습니다. 40초 더 느려짐 기본적으로 50MB 상당의 데이터를 복사합니다.
현실 세계에서는 이러한 성능 저하가 영향을 미칩니다. 어느 외부 저장소에 저장된 파일. 이는 /sdcard에 대용량 파일을 저장하는 지도, 수많은 음악 파일을 저장하는 음악 앱, 카메라 앱 및 사진 등과 같은 앱을 의미합니다. 외부 저장소와 관련하여 수행되는 모든 I/O 작업은 FUSE 오버헤드의 영향을 받습니다. 그러나 I/O 오버헤드가 FUSE의 유일한 문제는 아닙니다.
문제 #2 - 이중 캐싱
데이터 캐싱은 데이터 액세스 성능을 향상시키는 데 중요합니다. Linux 커널은 필수 데이터 조각을 메모리에 저장함으로써 필요할 때 해당 데이터를 신속하게 불러올 수 있습니다. 그러나 FUSE가 구현되는 방식으로 인해 Android는 필요한 캐시 양의 두 배를 저장합니다.
Kowalczyk 씨가 보여주듯이 10MB 파일은 정확히 10MB로 캐시에 저장될 것으로 예상되지만 대신 캐시 크기까지 커집니다. 약 20MB 정도. Linux 커널 저장소는 페이지 캐시를 사용하여 데이터를 저장하므로 RAM이 적은 장치에서는 문제가 됩니다. 메모리. Kowalczyk 씨는 다음 접근 방식을 사용하여 이중 캐싱 문제를 테스트했습니다.
- 알려진 크기(테스트용, 10MB)로 파일을 생성합니다.
- /sdcard에 복사하세요.
- 페이지 캐시 삭제
- 페이지 캐시 사용에 대한 스냅샷 찍기
- 테스트 파일 읽기
- 페이지 캐시 사용에 대한 또 다른 스냅샷 찍기
그가 발견한 것은 테스트 전에는 241MB가 커널에서 페이지 캐시로 사용되고 있다는 것이었습니다. 그는 테스트 파일을 읽고 나면 페이지 캐시에 251MB가 활용될 것으로 예상했습니다. 대신에 그는 그 커널이 다음을 사용하고 있다는 것을 발견했습니다. 263MB 페이지 캐시의 경우 - 정보 예상했던 것의 두 배. 이러한 현상이 발생하는 이유는 데이터가 처음에 I/O 호출을 발행한 사용자 애플리케이션(FUSE)에 의해 먼저 캐시되고 두 번째로 sdcard 데몬(EXT4 FS)에 의해 캐시되기 때문입니다.
문제 #3 - FAT32의 불완전한 구현
Android 커뮤니티에서는 덜 널리 알려진 FUSE 에뮬레이션 FAT32 사용으로 인해 발생하는 두 가지 문제가 더 있습니다.
첫 번째는 잘못된 타임스탬프. 파일(예: 사진)을 전송했는데 타임스탬프가 잘못된 것을 발견했다면 이는 Android의 FUSE 구현 때문입니다. 이 문제는 위해 존재했다 연령. 좀 더 구체적으로 말하자면, 문제는 다음과 관련됩니다. 유타임() 파일의 액세스 및 수정 시간을 변경할 수 있는 시스템 호출입니다. 불행하게도 표준 사용자로서 sdcard 데몬에 대한 호출에는 이 시스템 호출을 실행할 수 있는 적절한 권한이 없습니다. 이에 대한 해결 방법이 있지만 다음을 수행해야 합니다. 루트 액세스 권한이 있습니다.
파일(예: 사진)을 전송했는데 타임스탬프가 잘못된 것을 발견했다면 이는 Android의 FUSE 구현 때문입니다.
다음 문제는 다음과 같은 것을 사용하는 기업에 더 관련됩니다. 스마트SD 카드. FUSE 이전에는 앱 제작자가 모니터링할 수 있었습니다. O_DIRECT 플래그 카드에 내장된 마이크로 컨트롤러와 통신하기 위해. FUSE를 사용하면 개발자는 캐시된 파일 버전에만 액세스할 수 있으며 마이크로 컨트롤러에서 보낸 명령은 볼 수 없습니다. 이는 부가 가치 microSD 카드와 통신하는 일부 기업/정부/은행 앱에서 문제가 됩니다.
SDCardFS용 퓨즈 덤핑
일부 OEM은 이러한 문제를 조기에 인식하고 FUSE를 대체할 커널 내 솔루션을 찾기 시작했습니다. 예를 들어 삼성이 개발했습니다. SDCardFS 이는 WrapFS를 기반으로 합니다. 이 커널 내 솔루션은 FUSE처럼 FAT32를 에뮬레이트하지만 위에서 언급한 I/O 오버헤드, 이중 캐싱 및 기타 문제를 해결합니다. (예, 그 점을 다시 한번 말씀드리겠습니다. Google이 현재 구현하고 있는 이 솔루션은 삼성의 작업을 기반으로 합니다.).
Google은 마침내 FUSE와 관련된 단점을 인정했으며, 이것이 바로 삼성이 개발한 커널 내 FAT32 에뮬레이션 계층으로 이동하기 시작한 이유입니다. 회사는 안내문에 언급된 바와 같이 Android 개발자 백스테이지 팟캐스트는 향후 커널 버전의 모든 장치에서 SDCardFS를 사용할 수 있도록 하기 위해 노력해 왔습니다. 현재 진행 상황을 볼 수 있습니다. AOSP에서 근무.
로서 앞서 설명한 Google 개발자, 커널 내 솔루션 구현 시 가장 큰 과제는 패키지 이름을 매핑하는 방법입니다. 패키지가 별도의 요청 없이 외부 저장소에 있는 자체 데이터에 액세스하는 데 필요한 애플리케이션 ID 권한. 그러나 그 진술은 1년 전에 이루어졌으며 우리 팀은 SDCardFS를 "차세대 혁신"이라고 부르는 지점에 도달했습니다. 그들은 이미 다음과 같은 사실을 확인했습니다. 두려운 타임스탬프 오류 FUSE에서 이탈한 덕분에 수정되었으므로 FUSE의 포기로 인해 어떤 변화가 일어날지 기대해 보겠습니다.
사실 확인에 대한 오해
기사를 여기까지 읽었다면 지금까지의 모든 내용을 따라잡아주셔서 감사합니다! 이 글을 쓰면서 나 자신이 가졌던 몇 가지 질문을 명확히 하고 싶었습니다.
- SDCardFS에는 실제 SD 카드와는 아무런 관련이 없습니다. /sdcard에 대한 I/O 액세스를 처리하기 때문에 이름이 붙여졌습니다. 기억하실 수 있듯이 /sdcard는 기기의 "외부" 저장소(앱이 미디어를 저장하는 곳)를 나타내는 오래된 레이블입니다.
- SDCardFS는 전통적인 파일 시스템이 아닌 FAT32, EXT4 또는 F2FS와 같습니다. 이는 하위 에뮬레이트된 파일 시스템(이 경우 /sdcard의 FAT32)에 명령을 전달하는 스택형 래퍼 파일 시스템입니다.
- MTP와 관련하여 변경되는 사항은 없습니다.. Google이 더 나은 프로토콜을 결정할 때까지 계속 MTP를 사용하여 컴퓨터와 파일을 주고받을 것입니다. 하지만 최소한 타임스탬프 오류는 수정될 것입니다!
- 앞서 언급했듯이 Google이 "외부 저장소"를 언급할 때 그들은 (모든 의도와 목적) 내부 /sdcard 가상 FAT32 파티션 또는 실제, 물리적, 이동식 microSD에 대해 이야기하고 있습니다. 카드. 용어가 혼란스럽기는 하지만 우리는 바로 이 용어에 놀랐습니다.
결론
FUSE에서 벗어나 커널 내 FAT32 에뮬레이션 계층(SDCardFS)을 구현함으로써 Google은 상당한 I/O 오버헤드, 이중 캐싱 제거, FUSE의 에뮬레이션과 관련된 일부 모호한 문제 해결 FAT32.
이러한 변경 사항은 커널에 적용되므로 주요 새 버전의 Android 없이도 출시될 수 있습니다. 일부 사용자는 이러한 변경 사항이 Android 8에서 공식적으로 구현되기를 기대하지만 그럴 수도 있습니다. 향후 Pixel 기기의 OTA에서 Google이 작업 중인 Linux 커널 버전 4.1을 가져오려면 에.
여러분 중 일부에게 SDCardFS는 새로운 개념이 아닙니다. 실제로 삼성 기기는 수년 동안 이 기능을 사용해 왔습니다(결국 삼성 기기에서 이 기능을 개발했습니다). 작년에 AOSP에 SDCardFS가 도입된 이후 일부 맞춤 ROM 및 커널 개발자는 이를 작업에 구현하기로 선택했습니다. CyanogenMOD는 한때 이를 구현하는 것을 고려했지만 사용자가 사진에 문제가 발생하자 이를 롤백했습니다. 그러나 Google이 이 프로젝트를 주도하게 되면서 향후 모든 기기의 Android 사용자가 FUSE를 포기함으로써 도입된 개선 사항을 활용할 수 있기를 바랍니다.