Reiser4 FS 개발자 Eduard Shishkin과의 두 번째 인터뷰

Reiser4 파일 시스템 개발자인 Eduard Shishkin과의 두 번째 인터뷰가 공개되었습니다.

시작하려면 독자들에게 귀하가 어디에서 누구를 위해 일하고 있는지 상기시켜 주십시오.

저는 독일 연구 센터의 Huawei Technologies에서 수석 스토리지 설계자로 일하고 있습니다. 가상화 부서에서는 데이터 스토리지의 다양한 측면을 다루고 있습니다. 내 활동은 특정 운영 체제와 관련이 없습니다.

현재 메인 커널 브랜치에 커밋하고 있나요?

아주 드물게, 고용주가 요구하는 경우에만 그렇습니다. 마지막으로 보낸 것은 약 9년 전이었습니다. 저는 XNUMXp 프로토콜(이 사업의 또 다른 이름은 VirtFS)을 사용하는 호스트에서 공유되는 스토리지의 처리량을 늘리기 위해 패치를 보냈습니다. 여기서 한 가지 중요한 점을 언급해야 합니다. 저는 오랫동안 Linux를 사용했지만 팬이 된 적이 없습니다. 즉, 다른 모든 것과 마찬가지로 "균등하게 호흡"합니다. 특히, 결점을 발견하면 최대 한 번만 지적할 수 있습니다. 그리고 당신이 누군가를 따르고 설득 할 수 있도록 이것은 일어나지 않을 것입니다.

지난번에는 10년 전 당신이 커널 개발 스타일에 대해 매우 비판적이었던 것을 기억합니다. 귀하(또는 기업)의 관점에서 볼 때 변경된 사항이 있습니까? 커뮤니티의 반응이 더 좋아졌습니까? 그렇지 않다면 누구의 책임이 있다고 생각하시나요?

나는 더 나은 변화를 본 적이 없습니다. 공동체의 주요 문제는 과학을 정치 기술, 개인적 관계, 다수 의견, 포퓰리즘, "내부 목소리"의 조언, 썩은 타협 등 과학 이외의 것으로 대체하는 것입니다. 컴퓨터 과학은 무엇보다도 정확한 과학입니다. 그리고 누군가가 "Linux 방식" 플래그 또는 다른 플래그 아래에서 2가 아닌 2x4에 대한 자신의 가치를 선언하기 시작하면 이것이 해를 끼치는 것 외에는 아무 것도 가져올 가능성이 없습니다.

모든 문제는 주로 결정을 내리는 사람들의 무능함과 교육 부족으로 인해 발생합니다. 관리자가 무능하면 객관적이고 적절한 결정을 내릴 수 없습니다. 그도 교양이 없다면 올바른 조언을 해줄 유능한 전문가를 찾을 수 없습니다. 높은 확률로 선택은 "겉보기에 옳은 것"이라고 말하는 사기꾼에게 떨어질 것입니다. 부패한 환경은 항상 무능하고 고독한 리더를 중심으로 전개됩니다. 더욱이 역사는 이와 관련하여 예외를 알지 못하며 공동체는 이에 대한 가장 명확한 확인입니다.

Btrfs 개발 진행 상황을 어떻게 평가합니까? 이 FS는 어린 시절 질병을 제거 했습니까? FS를 "가정용"으로 또는 기업용으로 어떻게 포지셔닝합니까?

나는 그것을 제거하지 않았습니다. 제가 11년 전에 언급한 모든 내용은 오늘날에도 여전히 유효합니다. 심각한 요구에 부적합하게 만드는 Btrfs의 문제점 중 하나는 여유 공간 문제입니다. 다른 FS가 파티션에 많은 여유 공간을 표시하는 상황에서 사용자가 새 디스크를 찾기 위해 저장소로 실행하라는 요청을 받는다는 사실에 대해서도 말하는 것이 아닙니다. 여유 공간 부족으로 인해 논리 볼륨에서 작업을 완료할 수 없는 것도 최악은 아닙니다. 최악의 상황은 권한이 없는 사용자가 거의 항상 디스크 할당량을 우회하고 매우 짧은 시간 내에 모든 사람의 여유 공간을 박탈할 수 있다는 것입니다.

이는 다음과 같습니다(Linux 커널 5.12에서 테스트됨). 새로 설치된 시스템에서 스크립트가 실행되면 루프에서 홈 디렉토리에 특정 이름의 파일을 생성하고 특정 오프셋에 데이터를 쓴 다음 해당 파일을 삭제합니다. 이 스크립트를 실행한 지 50분 후에는 특별한 일이 발생하지 않습니다. 15분 후에는 파티션에서 차지하는 공간의 비율이 약간 증가합니다. 4~XNUMX시간 후에는 XNUMX%에 도달합니다(초기 값은 XNUMX%). 그리고 XNUMX~XNUMX시간 작업한 후 "파티션에 여유 공간이 없습니다."라는 오류와 함께 스크립트가 충돌합니다. 그 후에는 더 이상 파티션에 XNUMXK 파일도 쓸 수 없습니다.

흥미로운 상황이 발생합니다. 결국 파티션에 아무것도 쓰지 않고 모든 여유 공간(약 85%)이 어딘가에서 사라졌습니다. 이러한 공격을 받는 섹션을 분석하면 크기가 수 바이트인 단 하나의 항목(키가 장착된 객체)만 포함하는 많은 트리 노드가 드러납니다. 즉, 이전에 디스크 공간의 15%를 차지했던 콘텐츠가 전체 파티션에 고르게 "번짐"되어 새 파일을 쓸 곳이 없게 되었습니다. 키가 기존의 모든 파일보다 크고 여유 공간이 있기 때문입니다. 파티션의 블록이 모두 소모되었습니다.

더욱이 이 모든 일은 기본 Btrfs 구성(스냅샷, 하위 볼륨 등 없음)에서 이미 발생하며 해당 FS에 파일 본문을 트리의 "조각"으로 저장하거나 익스텐트로 저장하기로 결정하는 방법은 중요하지 않습니다. 포맷되지 않은 블록) - 최종 결과는 동일합니다.

다른 업스트림 파일 시스템은 그러한 공격을 받을 수 없습니다(그들이 뭐라고 말하든). 나는 오래 전에 문제의 원인을 설명했습니다. 이것은 Btrfs의 B-트리 개념이 완전히 왜곡되어 자발적으로 또는 의도적으로 퇴화될 수 있다는 것입니다. 특히, 특정 부하에서 파일 시스템은 외부 도움 없이 자체적으로 작동하는 동안 지속적으로 "분리"됩니다. 모든 종류의 "긴급" 백그라운드 프로세스가 개별 데스크탑에서만 하루를 절약할 수 있다는 것은 분명합니다.

집단 서버에서는 공격자가 항상 "앞서 나갈" 수 있습니다. 시스템 관리자는 그를 정확히 괴롭힌 사람이 누구인지조차 판단할 수 없습니다. Btrfs에서 이 문제를 해결하는 가장 빠른 방법은 일반 B-트리의 구조를 복원하는 것입니다. 디스크 형식을 재설계하고 Btrfs 코드의 상당 부분을 다시 작성합니다. 개발자가 관련 알고리즘 및 데이터 구조에 대한 원본 기사를 엄격히 준수하고 "Linux"에서 관례적(그리고 권장되는) "깨진 전화" 게임을 하지 않았다면 디버깅을 포함하여 8~10년이 걸릴 것입니다. 방법".

여기에 개발자가 이 모든 것을 이해하는 데 필요한 시간도 추가해야 합니다. 이것이 더 어려워지는 곳입니다. 어쨌든 그들이 이해하기엔 10년은 부족했다. 글쎄요, 그때까지는 기적을 바랄 수 없습니다. “당신과 내가 몰랐던” 마운팅 옵션의 형태로 일어나지도 않고, “단순히 업무상의 문제”인 패치 형태로 준비하는 것도 아닐 것입니다. 그러한 성급한 "수정" 각각에 대해 나는 새로운 퇴보 시나리오를 제시할 것입니다. B-트리는 제가 가장 좋아하는 주제 중 하나입니다. 이러한 구조는 그 자체의 자유를 용납하지 않습니다!

Btrfs를 어떻게 배치합니까? 사용은커녕, 파일 시스템이라고 부를 수도 없는 존재. 정의에 따르면 FS는 Btrfs의 경우에는 볼 수 없는 "디스크 공간" 리소스의 효과적인 관리를 담당하는 OS 하위 시스템이기 때문입니다. 글쎄, 당신이 출근에 늦지 않기 위해 시계를 사러 가게에 왔고 시계 대신 최대 30 분 동안 타이머가 달린 전기 그릴을 팔았다고 상상해보십시오. 따라서 Btrfs의 상황은 더욱 악화됩니다.

메일링 리스트를 살펴보면서 드라이브 가격이 저렴하기 때문에 디스크 공간을 효과적으로 관리하는 것이 더 이상 적합하지 않다는 진술을 자주 접하게 됩니다. 이것은 완전히 말도 안되는 소리입니다. 효과적인 디스크 공간 관리자가 없으면 OS는 취약해지고 사용할 수 없게 됩니다. 머신의 디스크 용량에 관계없이.

RHEL의 Btrfs 지원 중단에 대한 의견을 묻고 싶습니다.

여기에는 특별히 언급할 내용이 없으며 모든 것이 매우 명확합니다. 그들은 또한 그것을 "기술 미리 보기"로 가지고 있었습니다. 그래서 저는 이 "미리보기"를 거치지 않았습니다. 이 라벨을 영원히 방치하지 마십시오! 그러나 완벽한 지원을 받아 설계상 결함이 있는 제품을 출시할 수는 없습니다. RHEL은 기업, 즉 규정된 상품-화폐 관계입니다. Red Hat은 Btrfs 메일링 리스트에서처럼 사용자를 괴롭힐 수 없습니다. 상황을 상상해 보십시오. 힘들게 번 돈을 디스크에 지불하고 귀하에게도 지원을 요청한 클라이언트는 아무 것도 기록하지 않은 후 디스크 공간이 어디로 갔는지 알고 싶어합니다. 이에 대해 당신은 그에게 무엇이라고 대답하시겠습니까?

더 나아가. Red Hat의 고객으로는 유명 대형 은행과 거래소가 있습니다. 언급된 Btrfs의 취약점을 기반으로 DoS 공격을 받으면 어떤 일이 일어날지 상상해 보십시오. 이 일에 대한 책임이 누구에게 있다고 생각하시나요? 저자가 어떤 책임도 지지 않는다고 쓰여 있는 GPL 라이센스 줄을 손가락질하려는 사람들에게 나는 즉시 "숨겨주세요! "라고 말할 것입니다. Red Hat이 답변해 드릴 것이며, 충분하지 않을 것 같습니다! 그러나 저는 Red Hat이 이런 종류의 문제에 직면하지 않는다는 것을 알고 있습니다. 제가 함께 일할 기회가 있었던 특히 강력한 QA 엔지니어 팀이 있기 때문입니다.

일부 회사가 엔터프라이즈 제품에서 Btrfs를 계속 지원하는 이유는 무엇입니까?

제품명에 접두사 "enterprise"가 붙는 것은 큰 의미가 없음을 참고하시기 바랍니다. 기업은 고객과의 계약 관계에 내재된 책임의 척도입니다. 저는 GNU/Linux를 기반으로 하는 기업인 RHEL을 하나만 알고 있습니다. 내 관점에서 다른 모든 것은 기업으로만 제시될 뿐 기업이 아닙니다. 마지막으로, 무언가에 대한 수요가 있으면 항상 공급이 있을 것입니다(우리의 경우 이것이 언급된 "지원"입니다). 다음을 포함하여 절대적으로 모든 것에 대한 수요가 있습니다. 그리고 사용할 수 없는 소프트웨어. 그러한 수요가 어떻게 형성되고 누가 이를 촉진하는지는 또 다른 주제입니다.

따라서 Facebook이 서버에 Btrfs를 배포했다는 소문이 돌았을 때 저는 어떤 결론도 내리지 않을 것입니다. 또한, 위의 이유로 해당 서버의 주소를 비밀로 유지하는 것이 좋습니다.

최근 XFS 코드를 정리하는 데 그토록 많은 노력을 기울인 이유는 무엇입니까? 결국 이것은 처음에는 타사 파일 시스템이며 ext4는 오랫동안 안정적이었고 이전의 똑같이 안정적인 버전과의 연속성을 가지고 있습니다. Red Hat은 XFS에 어떤 관심을 갖고 있습니까? 목적이 비슷한 두 개의 파일 시스템인 ext4와 XFS를 적극적으로 개발하는 것이 합리적입니까?

무엇이 동기를 부여했는지 기억이 나지 않습니다. Red Hat 고객으로부터 이니셔티브가 나왔을 가능성이 높습니다. 이런 종류의 연구가 수행되었던 것을 기억합니다. 업스트림의 일부 파일 시스템에서 새로운 세대의 고급 드라이브에 엄청난 수의 개체가 생성되었습니다. 결과에 따르면 XFS는 ext4보다 더 잘 동작했습니다. 그래서 그들은 그것을 가장 유망한 것으로 홍보하기 시작했습니다. 어쨌든 나는 여기서 놀라운 것을 찾지 않을 것입니다.

나에게는 송곳을 비누로 바꾼 것과 같습니다. ext4와 XFS를 개발하는 것은 의미가 없습니다. 병렬로 실행하거나 둘 중 하나를 선택할 수 있습니다. 이것으로는 좋은 일이 없을 것입니다. 자연에는 성장 잠재력이 많지만 성장할 여지가 없는 상황이 종종 있습니다. 이 경우 모든 사람이 손가락질하는 기괴하고 추악한 다양한 새로운 성장이 발생합니다 ( "아, 이생에서 볼 수없는 것!").

ext4, F2FS(Btrfs의 RAID는 말할 것도 없고)의 암호화 기능의 출현으로 레이어 위반 문제가 (부정적인 의미에서) 해결되었다고 생각하십니까?

일반적으로 모든 수준을 도입하고 위반 여부를 결정하는 것은 일반적으로 정책의 문제이므로 여기서는 어떤 것도 언급하지 않습니다. 레이어 위반의 객관적인 측면은 누구에게나 거의 관심이 없지만 "위로부터" 위반의 예, 즉 블록 레이어에 이미 존재하는 기능을 FS에서 구현하는 것을 사용하여 일부를 고려할 수 있습니다. 그러한 “위반”은 극히 드문 예외를 제외하고는 정당화됩니다. 이러한 각 경우에 대해 먼저 두 가지를 증명해야 합니다. 즉, 그것이 실제로 필요한지, 그리고 그렇게 함으로써 시스템 설계가 손상되지 않는다는 것입니다.

예를 들어, 전통적으로 블록 계층의 활동이었던 미러링은 파일 시스템 수준에서 구현하는 것이 합리적입니다. 다른 이유로. 예를 들어, 디스크 드라이브에서는 "자동" 데이터 손상(비트 부패)이 발생합니다. 이는 장치가 제대로 작동하지만 멀리 있는 퀘이사 등에서 방출되는 하드 감마 양자의 영향으로 블록 데이터가 예기치 않게 손상되는 경우입니다. 최악의 상황은 이 블록이 FS 시스템 블록(수퍼블록, 비트맵 블록, 스토리지 트리 노드 등)으로 판명되는 경우입니다. 이는 확실히 커널 패닉으로 이어질 것이기 때문입니다.

블록 레이어(소위 RAID 1)에서 제공하는 미러로는 이 문제를 해결할 수 없습니다. 글쎄요, 누군가 체크섬을 확인하고 오류가 발생한 경우 복제본을 읽어야 할까요? 또한 모든 것을 미러링하는 것이 아니라 메타데이터만 미러링하는 것이 합리적입니다. 일부 중요한 데이터(예: 중요한 응용 프로그램의 실행 파일)는 메타데이터로 저장될 수 있습니다. 이 경우 동일한 안전 보장을 받습니다. 나머지 데이터의 보호를 다른 하위 시스템(아마도 사용자 애플리케이션)에 맡기는 것이 합리적입니다. 우리는 이에 필요한 모든 조건을 제공했습니다.

이러한 "경제적인" 미러는 존재할 권리가 있으며 파일 시스템 수준에서만 효과적으로 구성할 수 있습니다. 그렇지 않으면 계층화 위반으로 인해 약간의 이점을 얻기 위해 중복된 코드로 하위 시스템이 복잡해집니다. 이에 대한 놀라운 예는 FS를 사용한 RAID-5 구현입니다. 이러한 솔루션(파일 시스템의 자체 RAID/LVM)은 아키텍처 측면에서 후자를 제거합니다. 또한 계층화 위반은 다양한 종류의 마케팅 사기꾼에 의해 "흐름에 따라 발생"한다는 점도 여기서 주목해야 합니다. 아무런 아이디어가 없으면 오랫동안 인접 수준에서 구현되어 온 기능이 하위 시스템에 추가되며 이는 매우 유용한 새로운 기능으로 제시되어 적극적으로 추진됩니다.

Reiser4는 "아래에서" 수준을 위반한 혐의로 기소되었습니다. 파일 시스템이 다른 모든 시스템처럼 모놀리식이 아니라 모듈식이라는 사실을 기반으로 상위 수준(VFS)이 수행해야 하는 작업을 수행한다는 근거 없는 가정이 이루어졌습니다.

ReiserFS v3.6, 예를 들어 JFS의 종말에 대해 이야기할 수 있습니까? 최근에는 코어에서 거의 주목을 받지 못했습니다. 그것들은 쓸모가 없나요?

여기서 우리는 소프트웨어 제품의 종말이 무엇을 의미하는지 정의할 필요가 있습니다. 한편으로 그들은 성공적으로 사용됩니다(결국 그것이 바로 그것이 그들이 만들어진 이유입니다). 이는 그들이 살아 있다는 것을 의미합니다. 반면에 JFS에 대해서는 말할 수 없지만(많이 알지 못함) ReiserFS(v3)는 새로운 트렌드에 적응하기가 매우 어렵습니다(실제로 테스트됨). 이는 미래의 개발자들이 그것에 주의를 기울이는 것이 아니라 적응하기 더 쉬운 것에 주의를 기울일 것임을 의미합니다. 이쪽에서 보면 아쉽게도 건축학적 측면에서는 죽었다는 것이 밝혀졌습니다. 나는 "도덕적으로 쓸모없다"는 개념을 전혀 조작하지 않을 것입니다. 예를 들어 옷장에는 잘 적용되지만 소프트웨어 제품에는 적용되지 않습니다. 어떤 것에는 열등감과 우월감이라는 개념이 있습니다. ReserFS v3는 이제 모든 면에서 Reiser4보다 열등하지만 일부 유형의 워크로드에서는 다른 모든 업스트림 FS보다 우수하다고 절대적으로 말할 수 있습니다.

FS Tux3 및 HAMMER/HAMMER2(DragonFly BSD용 FS) 개발에 대해 알고 계십니까?

예, 우리는 알고 있습니다. Tux3에서는 한때 스냅샷 기술(소위 "버전 포인터")에 관심이 있었지만 Reiser4에서는 다른 경로로 갈 가능성이 높습니다. 스냅샷 지원에 대해 오랫동안 고민해 왔지만 단순 Reiser4 볼륨에 대해서는 스냅샷을 어떻게 구현해야 할지 아직 결정하지 못했습니다. 사실 Ohad Rodeh가 제안한 새로운 "게으른" 참조 카운터 기술은 B-트리에만 작동합니다. 우리는 그것들을 가지고 있지 않습니다. Reiesr4에서 사용되는 데이터 구조의 경우 "게으른" 카운터가 정의되지 않습니다. 이를 도입하려면 아직 아무도 수행하지 않은 특정 알고리즘 문제를 해결해야 합니다.

HAMMER에 따르면: 작성자의 기사를 읽었습니다. 관심이 없다. 다시, B-트리. 이 데이터 구조는 절망적으로 오래되었습니다. 우리는 지난 세기에 그것을 버렸습니다.

CephFS/GlusterFS/etc와 같은 네트워크 클러스터 FS에 대한 수요 증가를 어떻게 평가합니까? 이러한 요구는 개발자의 우선순위가 네트워크 FS로 이동하고 로컬 FS에 대한 관심이 부족하다는 것을 의미합니까?

그렇습니다. 우선순위가 이렇게 바뀌었습니다. 로컬 파일 시스템의 개발이 정체되었습니다. 아쉽게도 지역 볼륨을 위해 중요한 일을 하는 것은 이제 매우 어렵고 모든 사람이 할 수 있는 것은 아닙니다. 아무도 그들의 발전에 투자하고 싶어하지 않습니다. 이는 상업 조직에 수학 연구에 돈을 할당하도록 요청하는 것과 거의 같습니다. 아무런 열정도 없이 그들은 새로운 정리로 어떻게 돈을 벌 수 있는지 물어볼 것입니다. 이제 로컬 FS는 마술처럼 "즉시 사용 가능"하고 "항상 작동해야 하는" 것이며, 작동하지 않으면 "예, 저 사람들이 무슨 생각을 하는 거죠!"와 같은 해결되지 않은 투덜거림을 유발합니다.

따라서 해당 분야에 여전히 많은 작업이 있음에도 불구하고 로컬 FS에 대한 관심이 부족합니다. 그리고 그렇습니다. 모두가 이미 존재하는 로컬 파일 시스템을 기반으로 구축된 분산 스토리지로 전환했습니다. 지금은 매우 유행합니다. "빅 데이터"라는 문구는 컨퍼런스, 워크샵, 큰 급여 등과 연관되어 많은 사람들에게 아드레날린을 솟구치게 만듭니다.

사용자 공간이 아닌 커널 공간에서 네트워크 파일 시스템을 구현하는 것이 원칙적으로 얼마나 합리적입니까?

아직 어디에도 구현되지 않은 매우 합리적인 접근 방식입니다. 일반적으로 네트워크 파일 시스템을 어떤 공간에 구현해야 하는가는 '양날의 검'이다. 자, 예를 살펴보겠습니다. 클라이언트가 원격 시스템에 데이터를 기록했습니다. 그들은 더티 페이지 형태로 그녀의 페이지 캐시에 들어갔습니다. 이것은 커널 공간의 "씬 게이트웨이" 네트워크 파일 시스템을 위한 작업입니다. 그러면 운영 체제는 조만간 해당 페이지를 디스크에 기록하여 해제하도록 요청할 것입니다. 그런 다음 IO 전달(송신) 네트워크 FS 모듈이 작동합니다. 이 페이지가 이동할 서버 시스템(서버 노드)을 결정합니다.

그런 다음 네트워크 스택이 인계받습니다(알고 있듯이 커널 공간에서 구현됩니다). 다음으로, 서버 노드는 데이터나 메타데이터가 포함된 패킷을 수신하고 백엔드 스토리지 모듈(즉, 커널 공간에서 작동하는 로컬 FS)에 이 모든 내용을 기록하도록 지시합니다. 그래서 우리는 "송신" 및 "수신" 모듈이 작동해야 하는 위치에 대한 질문을 줄였습니다. 해당 모듈 중 하나라도 사용자 공간에서 실행되면 필연적으로 컨텍스트 전환이 발생합니다(커널 서비스를 사용해야 하기 때문에). 이러한 스위치의 수는 구현 세부 사항에 따라 다릅니다.

이러한 스위치가 많으면 스토리지 처리량(I/O 성능)이 감소합니다. 백엔드 스토리지가 느린 디스크로 구성된 경우에는 큰 감소를 느끼지 못할 것입니다. 그러나 빠른 디스크(SSD, NVRAM 등)가 있는 경우 컨텍스트 전환은 이미 "병목 현상"이 되며 컨텍스트 전환을 절약하면 성능이 크게 향상될 수 있습니다. 비용을 절약하는 표준 방법은 모듈을 커널 공간으로 옮기는 것입니다. 예를 들어, 9p 서버를 QEMU에서 호스트 시스템의 커널로 이동하면 VirtFS 성능이 XNUMX배 향상된다는 사실을 발견했습니다.

물론 이것은 네트워크 FS는 아니지만 사물의 본질을 완전히 반영합니다. 이 최적화의 단점은 이식성 문제입니다. 일부에게는 후자가 중요할 수 있습니다. 예를 들어 GlusterFS에는 커널에 모듈이 전혀 없습니다. 덕분에 이제 NetBSD를 포함한 많은 플랫폼에서 작동합니다.

로컬 FS는 네트워크 FS에서 어떤 개념을 빌릴 수 있으며 그 반대의 경우도 가능합니까?

요즘 네트워크 FS는 일반적으로 로컬 FS에 대한 추가 기능을 가지고 있으므로 후자에서 무언가를 빌릴 수 있는 방법을 잘 모르겠습니다. 글쎄, 실제로 직원 4명으로 구성된 회사를 생각해 봅시다. 직원은 각자 자신의 일을 합니다. 한 사람은 배포하고, 다른 사람은 보내고, 세 번째는 받고, 네 번째는 매장합니다. 그리고 회사가 그것을 저장하는 직원으로부터 무엇을 빌릴 수 있는지에 대한 질문은 다소 잘못된 것처럼 들립니다. (회사는 오랫동안 그 직원에게서 빌릴 수 있었던 것을 이미 가지고 있었습니다).

그러나 로컬 FS는 네트워크 FS로부터 배울 점이 많습니다. 첫째, 높은 수준에서 논리 볼륨을 집계하는 방법을 배워야 합니다. 이제 소위 "고급" 로컬 파일 시스템은 LVM에서 빌린 "가상 장치" 기술(ZFS에서 처음 구현된 것과 동일한 감염 계층 위반)을 독점적으로 사용하여 논리 볼륨을 집계합니다. 즉, 가상 주소(블록 번호)를 실제 주소로 변환하고 그 반대의 변환은 낮은 수준에서(즉, 파일 시스템이 I/O 요청을 발행한 후) 발생합니다.

블록 레이어에 배열된 논리 볼륨(미러 아님)에 장치를 추가하거나 제거하면 이러한 "기능" 공급업체가 아무 말도 하지 않는 문제가 발생한다는 점에 유의하십시오. 나는 가상 장치에서는 모든 것이 괜찮은 반면, 엄청난 값에 도달할 수 있는 실제 장치의 조각화에 대해 이야기하고 있습니다. 그러나 가상 장치에 관심이 있는 사람은 거의 없습니다. 모든 사람이 실제 장치에서 일어나는 일에 관심이 있습니다. 그러나 ZFS와 유사한 FS(및 LVM과 관련된 모든 FS)는 가상 디스크 장치에서만 작동합니다(무료 디스크 주소 중에서 가상 디스크 주소 할당, 이러한 가상 장치 조각 모음 등). 그리고 그들은 실제 장치에서 무슨 일이 일어나고 있는지 전혀 모릅니다!

이제 가상 장치에 조각화가 전혀 없고(즉, 거대한 범위가 하나만 존재함) 논리 볼륨에 디스크를 추가한 다음 논리 볼륨에서 다른 임의의 디스크를 제거하고 재조정한다고 상상해 보십시오. 그리고 여러 번. 가상 장치에서는 여전히 같은 정도의 생활을 할 수 있지만 실제 장치에서는 좋은 것을 볼 수 없을 것이라고 상상하는 것은 어렵지 않습니다.

최악의 상황은 이 상황을 바로잡을 수도 없다는 것입니다! 여기서 할 수 있는 유일한 일은 파일 시스템에 가상 장치 조각 모음을 요청하는 것입니다. 그러나 그녀는 그곳에서 모든 것이 훌륭하다고 말할 것입니다. 범위는 하나 뿐이고 조각화는 0이며 이보다 더 좋을 수는 없습니다! 따라서 블록 수준에 배열된 논리 볼륨은 장치의 반복적인 추가/제거를 위한 것이 아닙니다. 좋은 의미에서는 블록 수준에서 논리 볼륨을 한 번만 조립하고 파일 시스템에 제공한 다음 다른 작업을 수행하지 않아도 됩니다.

또한 독립적인 FS+LVM 하위 시스템의 조합에서는 논리 볼륨이 집계되는 드라이브의 다양한 특성을 고려할 수 없습니다. 실제로 HDD와 솔리드 스테이트 장치로 논리 볼륨을 조립했다고 가정해 보겠습니다. 그러나 전자는 조각 모음이 필요하고 후자는 조각 모음이 필요하지 않습니다. 후자의 경우 폐기 요청을 발행해야 하지만 전자의 경우 폐기 요청을 발행하지 않아야 합니다. 그러나 이 조합에서는 이러한 선택성을 입증하기가 매우 어렵습니다.

파일 시스템에 자신만의 LVM을 생성한 후에도 상황은 그다지 나아지지 않습니다. 더욱이, 이렇게 하면 실제로 미래에 개선할 가능성이 없어집니다. 이건 정말 나빠. 다양한 유형의 드라이브가 동일한 시스템에 있을 수 있습니다. 그리고 파일 시스템이 이들을 구별하지 못한다면 누가 할 것입니까?

또 다른 문제는 소위 기다리는 것입니다. "Write-Anywhere" 파일 시스템(마운트 중에 적절한 트랜잭션 모델을 지정한 경우 Reiser4도 포함됨) 이러한 파일 시스템은 전례 없는 강력한 조각 모음 도구를 제공해야 합니다. 그리고 낮은 수준의 볼륨 관리자는 여기서 도움이 되지 않고 방해만 됩니다. 사실 이러한 관리자를 사용하면 FS는 하나의 장치, 즉 가상 장치의 사용 가능한 블록 맵을 저장합니다. 따라서 가상 장치에 대해서만 조각 모음을 수행할 수 있습니다. 이는 조각 모음이 거대한 단일 가상 주소 공간에서 오랫동안 작동한다는 것을 의미합니다.

그리고 무작위 덮어쓰기를 수행하는 사용자가 많은 경우 이러한 조각 모음의 유용한 효과는 0으로 줄어듭니다. 귀하의 시스템은 필연적으로 속도가 느려지기 시작하고 실망스러운 진단 "깨진 디자인" 앞에서 손을 접으면됩니다. 동일한 주소 공간에서 실행되는 여러 조각 모음은 서로 방해만 합니다. 각 실제 장치에 대해 자신만의 여유 블록 맵을 유지 관리한다면 완전히 다른 문제입니다. 이렇게 하면 조각 모음 프로세스가 효과적으로 병렬화됩니다.

그러나 이는 높은 수준의 논리 볼륨 관리자가 있는 경우에만 수행할 수 있습니다. 그러한 관리자가 있는 로컬 파일 시스템은 이전에는 존재하지 않았습니다(적어도 저는 그것에 대해 모릅니다). 네트워크 파일 시스템(예: GlusterFS)에만 이러한 관리자가 있었습니다. 또 다른 매우 중요한 예는 볼륨 무결성 검사(fsck) 유틸리티입니다. 각 하위 볼륨에 대한 사용 가능한 블록의 독립적인 맵을 저장하면 논리 볼륨을 확인하는 절차를 효과적으로 병렬화할 수 있습니다. 즉, 높은 수준의 관리자가 있는 논리 볼륨이 더 잘 확장됩니다.

또한 낮은 수준의 볼륨 관리자를 사용하면 전체 기능을 갖춘 스냅샷을 구성할 수 없습니다. LVM 및 ZFS와 유사한 파일 시스템을 사용하면 로컬 스냅샷만 생성할 수 있고 글로벌 스냅샷은 생성할 수 없습니다. 로컬 스냅샷을 사용하면 일반 파일 작업만 즉시 롤백할 수 있습니다. 그리고 누구도 논리 볼륨 작업(장치 추가/제거)을 롤백하지 않습니다. 예를 들어 살펴보겠습니다. 특정 시점에 100개의 파일을 포함하는 두 장치 A와 B의 논리 볼륨이 있는 경우 시스템 S의 스냅샷을 찍은 다음 또 다른 XNUMX개의 파일을 생성합니다.

그런 다음 장치 C를 볼륨에 추가하고 마지막으로 시스템을 스냅샷 S로 롤백합니다. 질문: S로 롤백한 후 논리 볼륨에 포함되는 파일과 장치 수는 몇 개입니까? 짐작할 수 있듯이 100개의 파일이 있지만 3개의 장치가 있습니다. 이는 동일한 장치 A, B 및 C이지만 스냅샷이 생성될 당시 시스템에는 두 개의 장치(A 및 B)만 있었습니다. ). 장치 C 추가 작업은 롤백되지 않았으며 이제 컴퓨터에서 장치 C를 제거하면 데이터가 손상되므로 삭제하기 전에 먼저 비용이 많이 드는 작업을 수행하여 재조정 논리 볼륨에서 장치를 제거해야 합니다. 모든 데이터를 장치 C에서 장치 A와 B로 분산시킵니다. 그러나 FS가 전역 스냅샷을 지원하는 경우 이러한 재조정이 필요하지 않으며 S로 즉시 롤백한 후 컴퓨터에서 장치 C를 안전하게 제거할 수 있습니다.

따라서 글로벌 스냅샷은 많은 양의 데이터가 있는 논리 볼륨(논리 볼륨으로)에서 장치를 제거(추가)하는 데 비용이 많이 드는 것을 피할 수 있기 때문에 좋습니다(물론 시스템 "스냅샷"을 기억하는 경우) 적시에). 스냅샷을 생성하고 파일 시스템을 스냅샷으로 롤백하는 것은 즉각적인 작업이라는 점을 상기시켜 드리겠습니다. 질문이 생길 수 있습니다. 3일이 걸린 논리 볼륨 작업을 즉시 롤백하는 것이 어떻게 가능합니까? 하지만 가능합니다! 파일 시스템이 올바르게 설계된 경우. 나는 XNUMX년 전 이런 'XNUMXD 스냅샷' 아이디어를 생각해냈고, 지난해 이 기술에 대한 특허를 취득했다.

로컬 FS가 네트워크 FS에서 배워야 할 다음 사항은 네트워크 FS가 별도의 시스템(소위 메타데이터 서버)에 메타데이터를 저장하는 것과 동일한 방식으로 별도의 장치에 메타데이터를 저장하는 것입니다. 주로 메타데이터를 사용하여 작업하는 애플리케이션이 있으며 이러한 애플리케이션은 값비싼 고성능 저장 장치에 메타데이터를 배치하여 크게 가속화할 수 있습니다. FS+LVM 조합을 사용하면 이러한 선택성을 보여줄 수 없습니다. LVM은 전달한 블록에 무엇이 있는지(데이터 또는 메타데이터) 알 수 없습니다.

FS+LVM 조합에 비해 FS에서 자신만의 하위 수준 LVM을 구현하면 큰 이점을 얻을 수 없지만, FS를 복잡하게 만들어 나중에 코드 작업이 불가능하게 만드는 것이 가장 좋습니다. 가상 장치로 돌진한 ZFS와 Btrfs는 모두 계층화 위반으로 인해 아키텍처 측면에서 시스템이 어떻게 종료되는지 보여주는 명확한 예입니다. 또한 파일 시스템에 자체 하위 수준 LVM을 설치할 필요가 없습니다. 대신 일부 네트워크 파일 시스템이 다른 시스템(스토리지 노드)에서 수행하는 것처럼 장치를 높은 수준의 논리 볼륨으로 집계해야 합니다. 사실, 그들은 나쁜 알고리즘을 사용하기 때문에 역겨운 일을 합니다.

정말 끔찍한 알고리즘의 예로는 GlusterFS 파일 시스템의 DHT 변환기와 Ceph 파일 시스템의 소위 CRUSH 맵이 있습니다. 내가 본 알고리즘 중 어느 것도 단순성과 우수한 확장성 측면에서 나를 만족시키지 못했습니다. 그래서 저는 대수학을 기억하고 모든 것을 스스로 발명해야 했습니다. 2015년에 해시 함수에 대한 번들을 실험하던 중 나에게 맞는 것을 생각해내고 특허를 냈습니다. 이제 이 모든 것을 실천에 옮기려는 시도는 성공적이었다고 말할 수 있습니다. 새로운 접근 방식에서는 확장성 문제가 발생하지 않습니다.

예, 각 하위 볼륨에는 메모리의 슈퍼블록과 같은 별도의 구조가 필요합니다. 이거 많이 무섭나요? 일반적으로 나는 누가 "바다를 끓이고" 하나의 로컬 시스템에 수십만 개 이상의 장치로 구성된 논리 볼륨을 생성할지 모릅니다. 누구든지 나에게 이것을 설명해 주시면 매우 감사하겠습니다. 그 동안 나에게 이것은 마케팅 헛소리입니다.

커널 블록 장치 하위 시스템의 변경 사항(예: blk-mq 모양)이 FS 구현 요구 사항에 어떤 영향을 미쳤습니까?

그들은 아무런 영향을 미치지 않았습니다. 새로운 FS를 설계하는 데 필요한 블록 레이어에서 무슨 일이 일어날지 모르겠습니다. 이러한 하위 시스템의 상호 작용 인터페이스는 매우 열악합니다. 드라이버 측면에서 FS는 새로운 유형의 드라이브 출현에 의해서만 영향을 받아야 하며, 블록 레이어가 먼저 조정된 다음 FS가 조정됩니다(reiser4의 경우 이는 새 플러그인의 출현을 의미함).

새로운 유형의 미디어(예: SMR 또는 SSD의 편재성)의 출현은 파일 시스템 설계에 근본적으로 새로운 과제를 의미합니까?

예. 그리고 이것은 FS 개발에 대한 일반적인 인센티브입니다. 도전 과제는 다를 수 있고 완전히 예상치 못한 것일 수도 있습니다. 예를 들어, I/O 작업 속도가 데이터 조각의 크기와 오프셋에 따라 크게 좌우되는 드라이브에 대해 들었습니다. FS 블록의 크기가 페이지 크기를 초과할 수 없는 Linux에서는 이러한 드라이브가 기본적으로 전체 기능을 표시하지 않습니다. 그러나 파일 시스템이 올바르게 설계되면 더 많은 것을 얻을 수 있는 기회가 있습니다.

당신 외에 현재 Reiser4 코드를 사용하고 있는 사람은 몇 명입니까?

내가 원하는 것보다 적지 만 급격한 자원 부족도 경험하지 않습니다. 나는 Reiser4의 개발 속도에 매우 만족하고 있습니다. 나는 "말을 운전"하지 않을 것입니다. 이것은 올바른 지역이 아닙니다. 여기에 “조용히 운전하면 계속 갑니다!” 최신 파일 시스템은 가장 복잡한 커널 하위 시스템으로, 잘못된 설계 결정으로 인해 이후 수년간의 인간 작업이 취소될 수 있습니다.

무언가를 구현하기 위해 자원 봉사자를 제공함으로써 저는 항상 그 노력이 심각한 요구에 따라 필요할 수 있는 올바른 결과로 이어질 것이라고 항상 보장합니다. 아시다시피 그러한 보장은 한 번에 많이 있을 수 없습니다. 동시에, 나는 분명히 사용할 수 없는 소프트웨어의 "기능"을 뻔뻔하게 홍보하고 수백 명의 사용자와 개발자를 속이는 동시에 커널 정상 회담에 앉아 미소를 짓는 "인물"을 참을 수 없습니다.

Reiser4의 개발을 지원하겠다는 의사를 밝힌 회사가 있습니까?

예, 다음과 같은 제안이 있었습니다. 그리고 주요 벤더로부터. 하지만 그러기 위해서는 다른 나라로 이주해야 했습니다. 안타깝게도 저는 더 이상 30 살이 아니기 때문에 첫 휘파람 소리에 그렇게 헤어지고 떠날 수는 없습니다.

현재 Reiser4에는 어떤 기능이 없나요?

ReiserFS(v3)에 있는 것과 유사한 단순 볼륨에는 "크기 조정" 기능이 없습니다. 또한 DIRECT_IO 플래그를 사용한 파일 작업은 손상되지 않습니다. 다음으로, 볼륨을 고정된 크기가 없고 독립적인 볼륨으로 마운트할 수 있는 "의미론적 하위 볼륨"으로 분리할 수 있기를 바랍니다. 이러한 문제는 "실제"에 손을 대고 싶은 초보자에게 좋습니다.

그리고 마지막으로 구현과 관리가 간단한 네트워크 논리 볼륨을 갖고 싶습니다(최신 알고리즘은 이미 이를 허용함). 그러나 Reiser4가 결코 가질 수 없는 것은 RAID-Z, 스크럽, 여유 공간 캐시, 128비트 변수 및 일부 파일 시스템 개발자들 사이의 아이디어 부족을 배경으로 발생한 기타 말도 안되는 마케팅입니다.

필요한 모든 것을 플러그인으로 구현할 수 있나요?

이를 구현하는 인터페이스와 플러그인(모듈)에 대해서만 이야기한다면 모든 것이 아닙니다. 그러나 이러한 인터페이스에 관계도 도입한다면 무엇보다도 이미 사용할 수 있는 더 높은 다형성의 개념을 갖게 될 것입니다. 가상으로 객체 지향 런타임 시스템을 정지하고 동일한 X 인터페이스를 구현하는 다른 플러그인을 가리키도록 명령 포인터의 값을 변경한 다음 시스템이 계속 실행되도록 정지를 해제했다고 가정해 보십시오.

최종 사용자가 이러한 "대체"를 알아차리지 못하는 경우 시스템이 X 인터페이스에서 0차 다형성을 갖는다고 말합니다(또는 X 인터페이스에서 시스템이 이질적이라는 것은 동일한 의미입니다). 이제 인터페이스 세트가 있을 뿐만 아니라 인터페이스에 대한 관계도 있는 경우(인터페이스 그래프) 이미 모든 인터페이스의 "이웃"에 있는 시스템의 이질성을 특징으로 하는 더 높은 차수의 다형성을 도입할 수 있습니다. 이런 분류는 오래전에 소개한 적이 있는데, 아쉽게도 그런 일은 한 번도 없었습니다.

따라서 플러그인과 더 높은 다형성의 도움으로 알려진 기능을 설명할 수 있을 뿐만 아니라 언급된 적도 없는 기능을 "예측"할 수 있습니다. 이를 엄밀히 증명할 수는 없지만, 반례도 아직 모릅니다. 전반적으로 이 질문은 나에게 펠릭스 클라인의 "에를랑겐 프로그램"을 생각나게 했습니다. 한때 그는 모든 기하학을 대수학(구체적으로는 군론)의 한 분야로 표현하려고 노력했습니다.

이제 주요 질문으로 돌아가겠습니다. Reiser4를 메인 코어로 승격시키는 작업은 어떻게 진행되고 있나요? 지난 인터뷰에서 말씀하셨던 이 파일 시스템의 아키텍처에 관한 출판물이 있었나요? 당신의 관점에서 이 질문은 얼마나 관련성이 있습니까?

일반적으로 우리는 3년 동안 본점에 포함을 요청해 왔습니다. 풀 요청이 이루어진 공개 스레드에서 Reiser의 마지막 댓글에는 답변이 없습니다. 따라서 모든 추가 질문은 우리를 위한 것이 아닙니다. 저는 개인적으로 왜 특정 운영 체제에 "병합"해야 하는지 이해하지 못합니다. Linux에서는 빛이 쐐기처럼 수렴되지 않았습니다. 따라서 서로 다른 OS에 대한 여러 분기 포트가 있는 별도의 저장소가 있습니다. 필요한 사람은 누구나 해당 포트를 복제하고 이를 사용하여 원하는 모든 작업을 수행할 수 있습니다(물론 라이선스 내에서). 글쎄, 누군가가 필요하지 않다면 그것은 내 문제가 아닙니다. 이 시점에서 나는 "메인 리눅스 커널로의 승격" 문제가 해결된 것으로 간주할 것을 제안합니다.

FS 아키텍처에 대한 출판물은 관련이 있지만 지금까지 나는 새로운 결과를 얻을 시간만 찾았으며 이것이 더 높은 우선순위라고 생각합니다. 또 다른 것은 제가 수학자이고 수학에서 모든 출판물은 정리와 그 증명의 요약이라는 것입니다. 증거 없이 거기에 무엇이든 게시하는 것은 나쁜 취향의 표시입니다. FS 아키텍처에 대한 진술을 철저하게 증명하거나 반증한다면 그 결과는 통과하기 매우 어려울 정도로 더미가 될 것입니다. 누가 필요합니까? 이것이 아마도 소스 코드와 그에 대한 주석 등 모든 것이 이전 형식으로 계속 유지되는 이유일 것입니다.

지난 몇 년 동안 Reiser4의 새로운 기능은 무엇입니까?

오랫동안 기다려온 안정성이 드디어 실현되었습니다. 마지막으로 나타난 버그 중 하나는 "삭제할 수 없는" 디렉터리를 생성하는 버그였습니다. 어려움은 이름 해시 충돌의 배경과 트리 노드에 있는 디렉터리 레코드의 특정 위치에서만 나타나는 것이었습니다. 그러나 나는 여전히 프로덕션에 Reiser4를 권장할 수 없습니다. 이를 위해서는 프로덕션 시스템 관리자와 적극적으로 상호 작용하여 일부 작업을 수행해야 합니다.

우리는 마침내 우리의 오랜 아이디어인 다양한 거래 모델을 구현했습니다. 이전에 Reiser4는 하드코딩된 Macdonald-Reiser 모델 하나만 실행했습니다. 이로 인해 디자인 문제가 발생했습니다. 특히, 이러한 트랜잭션 모델에서는 스냅샷이 불가능합니다. "OVERWRITE SET"이라는 원자 구성 요소에 의해 스냅샷이 손상됩니다. Reiser4는 현재 세 가지 트랜잭션 모델을 지원합니다. 그 중 하나(Write-Anywhere)에서 원자 구성 요소인 OVERWRITE SET에는 "사진을 찍을" 수 없는 시스템 페이지(디스크 비트맵 이미지 등)만 포함됩니다(닭고기와 달걀 문제).

따라서 이제 가능한 최상의 방법으로 사진을 구현할 수 있습니다. 다른 트랜잭션 모델에서는 수정된 모든 페이지가 OVERWRITE SET으로만 이동합니다(즉, 기본적으로 순수 저널링입니다). 이 모델은 Reiser4 파티션의 빠른 조각화에 대해 불만을 토로하는 사람들을 위한 것입니다. 이제 이 모델에서는 파티션이 ReiserFS(v3)를 사용할 때보다 더 빠르게 조각화되지 않습니다. 세 가지 기존 모델 모두 약간의 유보가 있지만 작업의 원자성을 보장하지만 원자성이 손실되고 섹션의 무결성만 보존하는 모델도 유용할 수 있습니다. 이러한 모델은 이미 이러한 기능 중 일부를 수행하고 있는 모든 종류의 애플리케이션(데이터베이스 등)에 유용할 수 있습니다. 이러한 모델을 Reiser4에 추가하는 것은 매우 쉽지만 아무도 나에게 묻지 않았고 개인적으로 필요하지 않았기 때문에 그렇게 하지 않았습니다.

메타데이터 체크섬이 나타났고 최근에 "경제적인" 미러(여전히 불안정한 자료)로 이를 보완했습니다. 블록의 체크섬이 실패하면 Reiser4는 즉시 복제 장치에서 해당 블록을 읽습니다. ZFS 및 Btrfs는 이를 수행할 수 없습니다. 설계상 이를 허용하지 않습니다. 여기서는 "스크럽"이라는 특별한 백그라운드 검색 프로세스를 실행하고 문제가 있는 블록에 도달할 때까지 기다려야 합니다. 프로그래머는 이러한 이벤트를 비유적으로 "목발"이라고 부릅니다.

그리고 마지막으로 ZFS, Btrfs, 블록 계층 및 FS+LVM 조합이 원칙적으로 제공할 수 없는 모든 기능(병렬 확장, O(1) 디스크 주소 할당자, 하위 볼륨 간 투명한 데이터 마이그레이션)을 제공하는 이기종 논리 볼륨이 등장했습니다. 후자에는 사용자 인터페이스도 있습니다. 이제 가장 자주 사용되는 데이터를 볼륨의 최고 성능 드라이브로 쉽게 이동할 수 있습니다.

또한, 더티 페이지를 해당 드라이브로 긴급하게 플러시하여 fsync(2)를 자주 호출하는 응용 프로그램의 속도를 크게 높일 수 있습니다. bcache라고 불리는 블록 레이어 기능은 그러한 행동의 자유를 전혀 제공하지 않는다는 점에 주목합니다. 새로운 논리 볼륨은 내 알고리즘을 기반으로 합니다(해당 특허가 있음). 소프트웨어는 이미 매우 안정적이므로 사용해 보고 성능을 측정하는 등의 작업이 가능합니다. 유일한 불편한 점은 현재 볼륨 구성을 수동으로 업데이트하고 어딘가에 저장해야 한다는 것입니다.

지금까지 나는 내 아이디어를 10% 정도 구현할 수 있었지만 가장 어렵다고 생각했던 일, 즉 reiser4에서 모든 지연된 작업을 수행하는 플래시 프로시저와 논리 볼륨을 연결하는 데 성공했습니다. 이 모든 것은 아직 실험적인 "format41" 브랜치에 있습니다.

Reiser4는 xfstests를 통과합니까?

적어도 마지막 릴리스를 준비할 때는 그랬습니다.

플러그인을 사용하여 Reiser4를 네트워크(클러스터) FS로 만드는 것이 원칙적으로 가능합니까?

그것은 가능하고 심지어 필요합니다! 적절하게 설계된 로컬 파일 시스템을 기반으로 네트워크 파일을 생성하면 결과가 매우 인상적일 것입니다! 최신 네트워크 FS에서는 로컬 FS를 사용하여 구현되는 백엔드 스토리지 수준이 만족스럽지 않습니다. 이 수준의 존재는 완전히 정당하지 않습니다. 네트워크 FS는 블록 레이어와 직접 상호 작용해야 하며 로컬 FS에 다른 서비스 파일 생성을 요청해서는 안 됩니다!

일반적으로 파일 시스템을 로컬과 네트워크로 나누는 것은 나쁜 것입니다. 이는 30년 전에 사용되었던 알고리즘의 불완전성으로 인해 발생했으며, 이를 대체할 만한 것은 아직 아무것도 없습니다. 이는 불필요한 소프트웨어 구성 요소(다양한 서비스 등)가 대량으로 나타나는 이유이기도 합니다. 좋은 의미에서는 커널 모듈 형태의 FS가 하나만 있어야 하고 각 시스템(클러스터 노드)에 사용자 유틸리티 세트가 설치되어 있어야 합니다. 이 FS는 로컬이자 네트워크입니다. 그리고 그 이상은 없습니다!

Linux에서 Reiser4로 문제가 해결되지 않으면 FreeBSD용 FS를 제안하고 싶습니다(이전 인터뷰에서 인용: "...FreeBSD...는 학문적 뿌리를 가지고 있습니다... 그리고 이는 높은 확률로 우리가 개발자들과 공통 언어를 찾을 것입니다”) ?

방금 알아낸 바와 같이 Linux에서는 모든 것이 이미 완벽하게 작동했습니다. 저장소의 마스터 브랜치 형태로 작동하는 별도의 Reiser4 포트가 있습니다. 나는 FreeBSD를 잊지 않았습니다! 권하다! 저는 FreeBSD의 내부를 잘 아시는 분들과 긴밀히 협력할 준비가 되어 있습니다. 그건 그렇고, 내가 그들의 커뮤니티에서 정말 좋아하는 점은 한 명의 영구 개인에 대한 정부의 속임수와는 아무런 관련이 없는 업데이트된 독립적 전문가 협의회에 의해 결정이 내려진다는 것입니다.

현재 Linux 사용자 커뮤니티를 어떻게 평가하시나요? 좀 더 '팝'해졌나요?

내 작업의 특성상 이것을 평가하는 것은 상당히 어렵습니다. 대부분의 사용자는 버그 보고서와 섹션 수정 요청을 가지고 나에게 왔습니다. 사용자는 사용자입니다. 일부는 더 정통하고 일부는 덜합니다. 모든 사람은 동일하게 대우받습니다. 글쎄, 사용자가 내 지시를 무시한다면 실례합니다. 무시 명령은 나에게도 입력됩니다.

향후 5~10년 동안 파일 시스템의 발전을 예측하는 것이 가능합니까? FS 개발자가 직면할 수 있는 주요 과제는 무엇이라고 생각하시나요?

그렇습니다. 그러한 예측을 하는 것은 어렵지 않습니다. 오랫동안 업스트림에서는 파일 시스템 개발이 이루어지지 않았습니다. 그런 모습이 만들어질 뿐입니다. 로컬 파일 시스템 개발자는 잘못된 설계와 관련된 문제에 직면했습니다. 여기서 주의할 점이 있습니다. 나는 소위 "저장", "핥기", 코드 이식을 개발 및 개발이라고 생각하지 않습니다. 그리고 나는 이미 설명한 이유로 “Btrfs”라는 오해를 발전으로 분류하지 않습니다.

각 패치는 문제를 더욱 악화시킬 뿐입니다. 잘. 그리고 "모든 것이 역사하는" 다양한 종류의 "전도자"가 항상 있습니다. 기본적으로 이들은 강의를 건너 뛰는 학생과 학생들입니다. 상상해 보세요. 그 사람에게는 효과가 있지만 교수에게는 그렇지 않습니다. 이것은 얼마나 아드레날린이 솟구치는가! 내 관점에서 볼 때 가장 큰 피해는 Btrfs의 멋진 기능을 systemd, docker 등과 같은 모든 종류의 레이어에 열정적으로 "고정"하려고 서두르는 "장인"에 의해 발생합니다. -이것은 이미 전이와 유사합니다.

이제 4년에서 4년에 대한 예측을 해보겠습니다. 나는 이미 ReiserXNUMX에서 우리가 할 일을 간략하게 나열했습니다. 업스트림 지역 FS 개발자의 주요 과제는 급여에 맞는 적절한 일을 수행할 수 없다는 것입니다(예, 이미 그렇게 되었습니다). 데이터 저장 분야에 대한 아무런 아이디어도 없이 불행한 VFS, XFS 및 extXNUMX를 패치하려고 계속 노력할 것입니다. VFS의 상황은 이러한 배경에서 특히 코믹해 보이며, 요리사도 없고 요리사도 없을 것으로 예상되는 레스토랑의 광란적인 현대화를 연상시킵니다.

이제 VFS 코드는 아무런 조건 없이 여러 메모리 페이지를 동시에 잠그고 해당 페이지에서 작동하도록 기본 FS를 초대합니다. 이는 Ext4의 삭제 작업 성능을 향상시키기 위해 도입되었지만 이해하기 쉽듯이 이러한 동시 잠금은 고급 트랜잭션 모델과 완전히 호환되지 않습니다. 즉, 커널에 일부 스마트 파일 시스템에 대한 지원을 단순히 추가할 수는 없습니다. Linux의 다른 영역의 상황은 어떤지 모르겠지만 파일 시스템에 관한 한 여기서의 모든 개발은 Torvalds가 실제로 추구하는 정책과 호환되지 않을 것입니다(학술 프로젝트는 쫓겨나고 사기꾼은 B-트리, 끝없는 신뢰 크레딧이 발행되는지 전혀 모릅니다). 따라서 느린 붕괴 과정이 설정되었습니다. 물론 그들은 그것을 '개발'이라고 치부하기 위해 온 힘을 다해 노력할 것이다.

또한, 파일 시스템의 "관리자"는 "스토리지"만으로는 많은 수익을 얻을 수 없다는 사실을 깨닫고 보다 수익성 있는 사업을 시도할 것입니다. 이는 일반적으로 분산 파일 시스템 및 가상화입니다. 아마도 그들은 유행하는 ZFS를 아직 존재하지 않는 다른 곳으로 이식할 것입니다. 그러나 업스트림의 모든 FS와 마찬가지로 새해 나무와 비슷합니다. 위에 다른 작은 물건을 걸 수 있다면 더 깊이 들어갈 수 없습니다. 저는 ZFS를 기반으로 진지한 기업 시스템을 구축하는 것이 가능하다는 점을 인정하지만, 지금은 미래에 대해 논의하고 있기 때문에 이 점에서 ZFS는 절망적이라고 말할 수밖에 없습니다. 가상 장치를 사용하여 사람들은 산소 공급을 차단했습니다. 자신과 미래 세대의 발전을 위해. ZFS는 과거의 일입니다. 그리고 ext4와 XFS는 그저께도 아닙니다.

'차세대 리눅스 파일 시스템'이라는 획기적인 컨셉에 대해서는 별도로 언급할 가치가 있다. 이는 말하자면 Linux에서 특정 문자 뒤에 "파일 시스템의 미래를 고정"할 수 있는 기회를 위해 만들어진 완전히 정치적이고 마케팅적인 프로젝트입니다. 사실 Linux는 "그저 재미를 위해" 사용되었습니다. 그러나 이제는 주로 돈을 버는 기계입니다. 가능한 모든 방법으로 만들어졌습니다. 예를 들어, 좋은 소프트웨어 제품을 만드는 것은 매우 어렵지만 똑똑한 "개발자"는 전혀 긴장할 필요가 없다는 것을 오랫동안 깨달았습니다. 모든 종류의 공개에서 발표되고 홍보된 존재하지 않는 소프트웨어를 성공적으로 판매할 수 있습니다. 이벤트 - 가장 중요한 것은 프레젠테이션 슬라이드에 더 많은 "기능"이 포함되어야 한다는 것입니다.

결과에 대해 10년 동안 안전하게 협상할 수 있기 때문에 파일 시스템이 이에 적합합니다. 글쎄, 나중에 누군가가 바로 이 결과가 부족하다고 불평한다면 그는 파일 시스템에 대해 아무것도 이해하지 못하는 것입니다! 이것은 금융 피라미드를 연상시킵니다. 맨 위에는 이 혼란을 시작한 모험가와 "운이 좋은" 소수의 모험가가 있습니다. 그들은 "배당금을 인출"했습니다. 개발비를 받았고, 보수가 좋은 관리자 직업을 얻었으며, 컨퍼런스 등에 "출연"했습니다.

다음은 "불운"한 사람들입니다. 그들은 손실을 계산하고 사용할 수 없는 소프트웨어 제품을 프로덕션에 배포한 결과를 처리합니다. 그 중 더 많은 것이 있습니다. 음, 피라미드의 맨 아래에는 쓸모없는 코드를 "톱질"하는 수많은 개발자가 있습니다. 낭비된 시간은 되돌릴 수 없기 때문에 그들은 가장 큰 패자입니다. 그러한 피라미드는 Torvalds와 그의 동료들에게 매우 유익합니다. 그리고 이러한 피라미드가 많을수록 그들에게는 더 좋습니다. 그러한 피라미드에 먹이를 주려면 무엇이든 핵심으로 가져갈 수 있습니다. 물론 공개적으로는 그 반대라고 말합니다. 그러나 나는 말이 아니라 행동으로 판단합니다.

따라서 "Linux 파일 시스템의 미래"는 고도로 홍보되었지만 거의 사용할 수 없는 또 다른 소프트웨어입니다. Btrfs 이후에는 이러한 "미래"의 자리를 Bcachefs가 차지할 가능성이 높습니다. 이는 Linux 블록 계층을 파일 시스템과 교차시키려는 또 다른 시도입니다(나쁜 예는 전염성이 있습니다). 그리고 전형적인 것은 Btrfs와 동일한 문제가 있다는 것입니다. 나는 오랫동안 이것을 의심했지만, 왠지 저항할 수 없었고 코드를 살펴보았습니다. 그것은 사실입니다!

Bcachefs 및 Btrfs의 작성자는 FS를 만들 때 다른 사람의 소스를 적극적으로 사용했지만 그에 대해 거의 이해하지 못했습니다. 상황은 어린이 게임 "깨진 전화"를 매우 연상시킵니다. 그리고 이 코드가 커널에 어떻게 포함될지 대략적으로 상상할 수 있습니다. 실제로 아무도 "갈퀴"를 보지 못할 것입니다 (나중에 모두가 밟을 것입니다). 코드 스타일, 존재하지 않는 위반에 대한 비난 등에 대한 수많은 논쟁 끝에 작성자의 "충성도", 그가 다른 개발자와 얼마나 잘 "상호작용"하는지, 그리고 이 모든 것이 얼마나 성공적으로 이루어질 수 있는지에 대한 결론이 내려질 것입니다. 그런 다음 기업에 판매됩니다.

최종 결과는 누구에게도 관심이 없을 것입니다. 20년 전이었다면 아마도 관심을 가졌을 것입니다. 그러나 이제 질문은 다르게 제기됩니다. 이를 홍보하여 ​​향후 10년 내에 특정 사람들이 고용되도록 하는 것이 가능할까요? 그리고 아쉽게도 최종 결과에 대해 궁금해하는 것은 관례가 아닙니다.

일반적으로 파일 시스템을 처음부터 다시 만들려고 하지 말 것을 강력히 권합니다. 상당한 재정적 투자조차도 10년 안에 경쟁력 있는 제품을 얻기에는 충분하지 않기 때문입니다. 물론, 나는 커널에 "푸시"하려는 프로젝트가 아니라 심각한 프로젝트에 대해 이야기하고 있습니다. 따라서 자신을 표현하는 더 효과적인 방법은 우리처럼 실제 발전에 참여하는 것입니다. 물론 이는 쉽지 않습니다. 그러나 이는 모든 상위 수준 프로젝트의 경우입니다.

첫째, 내가 제시할 문제를 스스로 극복해야 합니다. 그 후에는 귀하의 의도가 심각하다는 것을 확신하고 도움을 시작하겠습니다. 전통적으로 우리는 자체 개발한 제품만 사용합니다. 압축 알고리즘과 일부 해시 함수는 예외입니다. 우리는 대부분의 스타트업에서 관례적으로 개발자를 컨퍼런스에 참석시키기 위해 파견하지 않으며, 앉아서 다른 사람들의 아이디어(“어쩌면 무슨 일이 일어날지”)를 결합하지도 않습니다.

우리는 모든 알고리즘을 직접 개발합니다. 저는 현재 데이터 저장 과학의 대수적, 조합적 측면에 관심이 있습니다. 특히, 유한 필드, 점근선, 부등식 증명. 일반 프로그래머를 위한 작업도 있지만 즉시 경고해야 합니다. "다른 FS를 보고 똑같이 수행"하라는 모든 제안은 무시됩니다. VFS를 통한 Linux와의 긴밀한 통합을 목표로 하는 패치도 여기에 포함될 예정입니다.

그래서 우리는 갈퀴는 없지만 어디로 움직여야 하는지 이해하고 있으며 이 방향이 옳다는 확신을 가지고 있습니다. 이러한 이해는 하늘에서 내려온 만나의 형태로 온 것이 아닙니다. 우리는 29년 간의 개발 경험을 갖고 있으며 두 개의 파일 시스템을 처음부터 작성했다는 점을 상기시켜 드립니다. 그리고 동일한 수의 데이터 복구 유틸리티가 있습니다. 그리고 이것은 많이 있습니다!

출처 : opennet.ru