이러한 것들을 내부적으로 제한하는 것은 무엇입니까?

긴 대답

ZFS의 제한은 컴퓨터에서 가장 빠른 산술 방법이기 때문에 고정 크기 정수를 기반으로합니다.

대안은 임의 정밀도 산술 이라고 하지만 본질적으로 느립니다 . 이것이 임의 정밀도 산술이 산술을 수행하는 기본 방법이 아닌 대부분의 프로그래밍 언어에서 추가 라이브러리 인 이유입니다. 이 예외는, 그러나 이들은 보통 수학 - 지향 DSL이 같은 bc또는 볼프람 언어 .

빠른 산술을 원하면 고정 크기 단어 인 마침표를 사용합니다.

임의 정밀도 연산에서 속도 히트는 컴퓨터의 RAM 내부의 나쁜 충분하지만, 파일 시스템이 모르는 경우에 얼마나 많은이 될 것이다는 RAM에 필요한 숫자의 모든로드하기 위해 만들 필요가 읽고 매우 비용이 많이 드는합니다. 임의의 크기의 정수를 기반으로하는 파일 시스템은 메타 데이터 블록의 크기를 미리 알고있는 파일 시스템에 비해 여러 디스크 적중에서 많은 추가 I / O를 필요로하므로 여러 블록에서 각 숫자를 합쳐야합니다.

이제 각 한계의 실질적인 수입에 대해 논의 해 보겠습니다.

맥스. 볼륨 크기

(2) ¹²⁸ 바이트 이미 효과적으로 무한하다. 대신 그 숫자를 대략 10 ³⁸ 바이트 로 쓸 수 있습니다. 즉 ,이 제한에 도달하려면 10 ^{개의 50 개의} 원자가 모두 데이터를 저장하는 데 사용되는 단일 지구 크기의 ZFS 풀이 있어야합니다. 바이트는 10 ¹² 원자 보다 크지 않은 요소에 의해 저장됩니다 .

10 ^{개의 12 개의} 원자는 많이 들리지만 실리콘은 약 47 피코 그램에 불과 합니다.

g 데이터의 밀도는 2.5 × 10 ^-13  최대 가능한 SD 카드를 1 TB이며 순수한 이루어지는되지 0.25g.¹ 마이크로 카드에 대해 무게이 기입으로, g / 바이트 마이크로 저장소 실리콘이지만 포장을 무시할 수는 없습니다. 지구 컴퓨터에서도 일부가 필요하기 때문입니다. 플라스틱의 밀도가 낮고 금속 핀의 밀도가 높을수록 평균적으로 실리콘과 거의 같은 밀도라고 가정합니다. 또한 칩 간 상호 연결 등을 설명하기 위해 여기에 약간의 슬롭이 필요합니다.

pico- anything 은 ^10-12 이므로 위의 47pg 및 ^2.5x10-13g  / B 숫자는 약 10 배 정도 떨어져 있습니다. 즉, 현재 가장 큰 microSD 카드에서 최대 크기의 단일 ZFS 풀을 구성하려면 첫 번째 근사치로 지구 크기의 행성 전체에 해당하는 원자를 사용해야 할 수도 있습니다. 실리콘, 탄소, 금 등의 적절한 혼합물에 가까운 무언가를 사용 하여 예상치를 날려 버릴 정도로 많은 슬래그로 끝나지 않습니다 .

여기에서 테이프 나 디스크와 같이 밀도가 높은 것 대신 플래시 스토리지를 사용하는 것이 불공평하다고 생각한다면 관련된 데이터 속도와 중복성 또는 장치 교체를 고려하지도 않았다는 사실을 고려하십시오. 이 지구 크기의 ZFS 풀은 교체 할 필요가없는 vdev 로 구성되며 합리적인 시간에 풀을 채울 수있을만큼 데이터를 빠르게 전송할 수 있다고 가정 해야합니다. 여기서는 솔리드 스테이트 스토리지 만 의미가 있습니다.

위의 근사값은 상당히 거칠고 저장 밀도는 계속 증가하지만 상황을 계속해서 살펴보십시오. 미래에는 최대 크기의 ZFS 풀을 구성하는이 스턴트를 시작하려면 여전히 전체 크러스트-투-클러스트를 사용해야합니다. 작은 행성 의 핵심 자원 .

맥스. 파일 크기

이제 우리는 행성 크기의 파일 시스템을 가지고 있습니다. 그 안에 저장된 파일의 크기에 대해 무엇을 말할 수 있습니까?

지구상의 모든 사람에게 동일한 크기의 풀을 제공합시다.

10 ³⁸  ÷ 10 ¹⁰  ≈ 10 ²⁸  ÷ 10 ¹⁹  ≈ 10 ⁹

이것은 풀의 크기를 Earth²의 인구로 나눈 값을 최대 파일 크기로 나눈 값입니다.

즉, 모든 사람은 지구 크기의 ZFS 스토리지 어레이의 작은 개인 조각에 최대 크기의 파일 10 억 개를 저장할 수 있습니다.

(이 예제에서 우리의 스토리지 어레이가 여전히 행성 크기라는 것이 신경 쓰이는 경우, 위의 첫 번째 제한에 도달하려면 그렇게 커야 했으므로이 예제에서는 계속 사용하는 것이 좋습니다. 여기.)

파일 당 최대 파일 크기는  ZFS에서 16EiB 이며 , 이는 오늘날 자체적으로 엄청나게 큰 것으로 간주되는 ext4의 최대 볼륨 크기보다 16 배 더 큽니다 .

누군가가 Planet ZFS (이전의 Earth) 조각을 사용하여 최대 크기의 ext4 디스크 이미지의 백업을 저장한다고 상상해보십시오. 더욱이이 미친 고객 (항상 한 tar명만 있음)은 ZFS의 최대 파일 크기 제한에 도달하기 위해 파일 당 16 개를 추가 하기로 결정했습니다 . 그렇게하더라도 해당 고객은 약 10 억 번 더 이를 다시 수행 할 여지가 있습니다 .

이 한계에 대해 걱정한다면, 해결해야 할 필요가 있다고 상상해야하는 문제입니다. 또한 해당 파일을 온라인 백업 서비스로 한 번 전송하는 데 필요한 데이터 대역폭을 확보하지 않아도됩니다 .

또한 지구 컴퓨터가 얼마나 가능성이 없는지 분명히합시다. 먼저 중력에 의해 자체적으로 붕괴되어 중심에서 녹지 않도록 만드는 방법을 알아 내야합니다. 그런 다음 남은 슬래그없이 지구상의 모든 단일 원자를 사용하여 그것을 제조하는 방법을 알아 내야합니다.

이제, 당신이 지구 컴퓨터의 표면을 지옥의 풍경으로 바꾸었기 때문에, 그 컴퓨터를 사용하려는 모든 사람들은 다른 어딘가에 살아야 할 것입니다. 사람들이 속도를 저주하는 것을 자주 듣는 곳입니다. 가벼운 지연은 지구 컴퓨터와 현재 살고있는 곳 사이의 모든 트랜잭션에 대기 시간을 추가합니다. 현재 10ms 이하의 인터넷 핑 시간이 문제라고 생각 한다면이 지구 컴퓨터를 만들 수 있도록 지구 인구를 달로 이동하면 키보드와 컴퓨터 사이 에 2.6 광초를 두는 것을 상상해보십시오 .

ZFS의 볼륨 및 파일 크기 제한은 공상 과학 소설이 많습니다.

맥스. 디렉토리 당 파일 수

2 ⁴⁸ 은 디렉토리 당 대략 10 ^{14 개의} 파일이며 ZFS를 플랫 파일 시스템 으로 취급하려는 응용 프로그램에서만 문제가 될 것 입니다.

인터넷에서 각 IP 주소에 대한 파일을 저장하는 인터넷 연구원을 상상해보십시오. 먼저 이전 IPv4 공간에서 여유 공간을 뺀 다음 이제 IPv6 주소를 사용하여 호스트에 추가 한 후 정확히 2 ^{32 개의} IP가 추적되고 있다고 가정 해 보겠습니다 . 이 연구원이 2 개 ¹⁶ — 65536 개 이상을 저장할 수있는 파일링 시스템을 구축해야하는 문제를 해결하려고합니다 ! — IP 당 파일?

이 연구원이 TCP 포트 당 파일도 저장한다고 가정 해 보겠습니다. 따라서 IP : 포트 조합 당 하나의 파일 만 사용 하면 2 ¹⁶ 배율을 먹었습니다 .

수정은 간단합니다. IP 별 파일을 IP 이름을 따서 명명 된 하위 디렉터리에 저장하고 포트 별 파일을 IP 별 파일이있는 디렉터리의 하위 디렉터리에 저장합니다. 이제 우리 연구원은 장기간의 글로벌 인터넷 모니터링 시스템에 충분한 IP : 포트 조합 당 10 ^{14 개의} 파일을 저장할 수 있습니다 .

ZFS의 디렉토리 크기 제한은 오늘날이 한계에 도달 할 수있는 실제 응용 프로그램을 알고 있기 때문에 "공상 과학 소설"이라고 부르는 것이 아닙니다.하지만 계층 구조의 힘으로 인해 한도.

이 제한은 주어진 디렉토리에서 파일을 찾는 데 필요한 데이터 구조가 RAM에 맞지 않도록 너무 크게 만드는 것을 방지하기 위해 이만큼 낮게 설정되었을 것입니다. 처음에이 문제를 방지하기 위해 데이터를 계층 적으로 구성 할 것을 권장합니다.

맥스. 파일 이름 길이

이 한도는 엄격 해 보이지만 실제로는 의미가 있습니다.

이 제한은 ZFS에서 발생하지 않습니다. 나는 그것이 4.2BSD의 FFS로 거슬러 올라간다고 생각합니다 . 인용구를 찾을 수 없지만이 한계가 어렸을 때 누군가 "할머니에게 보내는 짧은 편지"를위한 충분한 공간이라고 지적했습니다.

따라서 질문이 제기됩니다. 파일 이름을 그보다 더 설명 적으로 지정해야하는 이유는 무엇입니까? 그보다 더 큰 진정한 요구는 아마도 계층 구조를 필요로하며, 이때 계층 구조의 수준 수에 1을 더하여 제한을 곱합니다. 즉, 파일이 계층 구조에 3 단계 깊이 묻혀있는 경우 전체 경로 이름의 제한은 4 × 255 = 1020 자입니다.

궁극적으로이 한계는 기술적 한계가 아니라 인간의 한계입니다. 파일 이름은 사람이 사용하기위한 것이며 사람은 파일의 내용을 유용하게 설명하는 데 실제로 255 자 이상 필요하지 않습니다. 더 높은 제한은 도움이되지 않습니다. 인간은 그 이후로 더 긴 파일 이름에 대처할 수있는 능력을 얻지 못했기 때문에 제한은 오래되었습니다 (1983).

이상하게 보이는 "255"값의 출처를 묻는다면 8 비트 바이트 크기에 따른 제한입니다. 2 ⁸ 은 256이고 여기에 사용 된 N-1 값 은 파일 별 메타 데이터의 256 바이트 필드에서 파일 이름 문자열의 끝을 표시하기 위해 null 종결 자를 사용하고 있음을 의미 합니다.

짧은 대답

실질적으로 어떤 한계가 있습니까?

각주 :

1. 0.01g의 정확도로 지정된 눈금을 사용하여 이것을 측정했습니다.

2. 이 글을 쓰는 시점에서 75 억 5 천만 . 위에서, 우리는 이것을 10 ^10으로 반올림 하고 있으며, 세기 중반에 도달해야합니다 .