긴 대답

긴 대답

위키피디아에 따르면, ZFS에는 다음과 같은 제한 사항이 있습니다.

  • 최고. 볼륨 크기:256테라바이트(2 128 바이트)
  • 최고. 파일 크기:16엑사바이트(2 64 바이트)
  • 최고. 파일 수:
  • 최고. 파일 이름 길이: 255개의 ASCII 문자(유니코드와 같은 멀티바이트 문자 인코딩의 경우 더 적음)

왜 이러한 제한이 있습니까? 이러한 것들을 내부적으로 제한하는 것은 무엇입니까? ZFS가 이론적으로 볼륨 크기나 파일 이름 길이 등을 무제한으로 가질 수 없는 이유는 무엇입니까?

답변1

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

긴 대답

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

또 다른 방법이 호출됩니다.임의의 정밀 연산, 하지만본질적으로 느립니다. 이것이 바로 임의 정밀도 연산이 연산을 수행하는 기본 방법이 아니라 대부분의 프로그래밍 언어에서 추가 기능 라이브러리인 이유입니다. 예외도 있지만 일반적으로 수학 중심입니다.DSL좋다bc또는Wolfram 언어.

빠른 산술을 원할 경우 고정 크기 단어, 마침표를 사용할 수 있습니다.

컴퓨터 RAM의 임의 정밀도 연산으로 인한 속도 저하는 충분히 나쁩니다. 그러나 파일 시스템이 RAM에 필요한 모든 숫자를 로드하기 위해 필요한 읽기 횟수를 알지 못하는 경우에는매우값비싼. 임의 크기의 정수를 기반으로 하는 파일 시스템은 각 숫자를 여러 블록으로 모아야 하므로 메타데이터 블록의 크기를 미리 알고 있는 파일 시스템에 비해 여러 디스크 히트에서 많은 추가 I/O가 필요합니다.

이제 각 제한 사항의 실질적인 중요성에 대해 논의하겠습니다.

최고. 볼륨 크기

2 128 바이트는 실제로 무제한입니다. 이 숫자를 약 10 38 바이트 로 쓸 수 있습니다 . 즉, 해당 제한에 도달하려면 각 노드에 지구 크기의 ZFS 풀이 있어야 합니다.10 50 원자데이터를 저장하는 데 사용되는 각 바이트는 10 12 원자 보다 크지 않은 요소로 저장됩니다 .

10 12 원자는 많은 것처럼 들리지만,실리콘은 약 47피코그램에 불과합니다..

이 글을 쓰는 시점에서 microSD 저장소의 데이터 밀도(그램)는 2.5×10 -13g  /바이트입니다. 사용 가능한 가장 큰 SD 카드는 1TB이고 무게는 약 0.25g입니다. 실리콘이지만 지구 컴퓨터에도 실리콘이 필요하기 때문에 포장을 무시할 수 없습니다. 플라스틱의 밀도가 낮고 금속 핀의 밀도가 높을수록 평균적으로 실리콘과 거의 같은 밀도가 된다고 가정합니다. 또한 칩 간 상호 연결 등을 설명하기 위해 약간의 경사가 필요합니다.

아 웨이웨이-아무것은 10 -12 이므로 위의 47 pg 및 2.5×10 -13 g/B 수치  는 약 10배 정도 다릅니다. 즉, 현재 사용 가능한 가장 큰 microSD 카드를 사용하여 단일 최대 크기 ZFS 풀을 구축하려면 아마도 지구 크기의 행성 전체에 해당하는 원자를 사용해야 하며 이는 가까운 곳에 있는 경우에만 가능합니다. 실리콘, 탄소, 금 등의 올바른 조합으로 너무 많이 얻지 않도록광재예상을 초과했습니다.

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

위의 근사치는 매우 대략적이며 저장 밀도는 계속 증가하지만 이를 관점에서 생각해 보세요. 미래에 최대 크기의 ZFS 풀을 구축하는 스턴트를 수행하려면 여전히 총 ​​크러스트-투- 핵심 자원소행성.

최고. 파일 크기

그래서 우리는행성 크기의 파일 시스템지금. 여기에 저장된 파일의 크기에 대해 무엇을 말할 수 있습니까?

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

10 38  ¼ 10 10  ≒ 10 28  ¼ 10 19  ≒ 10 9

이는 풀 크기를 지구의 인구²로 나눈 값을 최대 파일 크기(정수로 표시)로 나눈 값입니다.

즉, 각 개인은 행성 크기의 ZFS 스토리지 어레이의 개인용 작은 조각에 최대 크기의 약 10억 개의 파일을 저장할 수 있습니다.

(이 예에서 스토리지 어레이가 여전히 행성 크기라는 사실이 마음에 들지 않으면 위의 첫 번째 제한에 도달하려면 그만큼 커야 하므로 여기 예에서는 계속 사용하는 것이 공평하다는 점을 기억하십시오. )

파일당 최대 파일 크기는 16입니다. 유럽 ​​은행ZFS에서는ext4 최대 볼륨 크기보다 16배 더 큼, 오늘날 그 자체로 엄청나게 큰 것으로 간주됩니다.

누군가가 Planet ZFS(이전 Earth) 슬라이스를 사용하여 최대 크기의 ext4 디스크 이미지 백업을 저장한다고 상상해 보세요. 게다가 이 미친 고객(항상 한 명은 있음)이 결정합니다.tar파일당 최대 16개는 ZFS 최대 파일 크기 제한에 도달하는 것입니다. 이 작업이 완료되면 고객은 여전히 ​​그렇게 할 수 있습니다.다시약 10억 번.

이런 한계를 걱정하려면 이런 종류의 문제를 해결해야 한다고 상상해야 합니다. 이는 해당 파일을 온라인 백업 서비스로 전송하는 데 필요한 데이터 대역폭도 고려하지 않습니다.한 번.

우리는 또한 지구 컴퓨터가 얼마나 가능성이 있는지 알아내야 합니다. 먼저, 중력에 의해 자체적으로 붕괴되거나 중앙에서 녹지 않고 그것을 만드는 방법을 알아내야 합니다. 그런 다음 남은 슬래그 없이 지구상의 모든 원자를 사용하여 그것을 만드는 방법을 알아내야 합니다.

이제, 당신이 지구의 컴퓨터 표면을 지옥으로 만들었기 때문에, 그 컴퓨터를 사용하려는 모든 사람은 다른 곳, 즉 사람들이 속도에 대해 저주하는 것을 끊임없이 듣는 곳에서 살아야 합니다. 즉, 지구의 컴퓨터에 비해 약간의 지연이 추가됩니다. 지금 살고 있는 곳 어디든 모든 거래 사이에. 오늘날의 10ms 이하의 인터넷 핑 시간이 문제라고 생각한다면 다음을 상상해 보십시오.2.6광초만약 우리가 지구의 인구를 달로 옮긴다면 우리는 이 지구 컴퓨터를 만들 수 있을 것입니다.

ZFS의 볼륨 및 파일 크기 제한은 공상 과학 소설의 내용입니다.

최고. 디렉터리당 파일 수

2 48 은 디렉터리당 약 10 14개 파일이며 이는 ZFS를 파일 시스템으로 처리하려는 응용 프로그램에서만 문제가 됩니다.플랫 파일 시스템.

인터넷 연구원이 인터넷의 모든 IP 주소에 대한 파일을 저장하고 있다고 상상해 보십시오. 먼저 이전 IPv4 공간에서 여유 공간을 뺀 다음 현재 IPv6 주소를 사용하는 호스트를 추가하여 산술이 원활하게 작동한다고 가정하면 정확히 2 32개의 IP가 추적됩니다. 이 연구원이 해결하려는 문제는 무엇입니까? 2 16 — 65536개 이상을 저장할 수 있는 파일 시스템을 구축해야 합니다! — IP별 문서화?

연구원이 각 TCP 포트에 대한 파일도 저장하므로 IP:포트 조합당 하나의 파일만 저장한다고 가정하면 2 16 승수를 소진합니다.

해결 방법은 간단합니다. 각 IP 파일을 IP 이름을 딴 하위 디렉터리에 저장하고, 각 포트 파일을 각 IP 파일이 들어 있는 디렉터리의 하위 디렉터리에 저장하면 됩니다. 우리 연구원들은 이제 각 IP:포트 조합에 대해 장기적인 글로벌 인터넷 모니터링 시스템에 충분한 10 14 파일을 저장할 수 있습니다.

ZFS의 디렉토리 크기 제한은 오늘날 실제 응용 프로그램에서 도달할 가능성이 높기 때문에 "공상 과학의 큰 제한"이라고 부르는 것이 아니지만 계층 구조의 힘은 을 만나면 다른 디렉토리를 추가할 수 있음을 의미합니다. 레이어: 제한 사항.

이 제한은 주어진 디렉토리에서 파일을 찾는 데 필요한 데이터 구조가 너무 커서 RAM에 맞지 않는 것을 방지하기 위해 너무 낮게 설정될 수 있습니다. 이 문제를 방지하려면 데이터를 계층적으로 구성하는 것이 좋습니다.

최고. 파일 이름 길이

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

이 제한은 ZFS에서 발생하지 않습니다. 나는 그것이 다시 돌아간다고 믿는다BSD의 4.2FFS. 인용은 못찾았는데 한도가 작았을 때 누군가가 "할머니에게 보내는 쪽지"를 적을 수 있을 만큼 공간이 충분하다고 지적하더군요.

그러면 다음과 같은 질문이 생깁니다. 왜 파일 이름을 그보다 더 설명적으로 지정해야 합니까? 이보다 더 큰 실제 요구 사항에는 계층 구조가 필요할 수 있으며, 이 경우 계층 구조의 수준 수에 1을 더한 값을 곱합니다. 즉, 파일이 계층 구조에서 3레벨에 묻혀 있으면 전체 경로 이름 제한은 4 × 255 = 1020자입니다.

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

이상하게 보이는 "255" 값이 어디서 나오는지 묻는다면 이는 8비트 바이트 크기에 따른 일부 제한 사항입니다. 2 8 은 256입니다. 여기서 사용된 N-1 값은 아마도 그들이 다음을 사용하고 있음을 의미할 것입니다.널 종결자각 파일의 메타데이터에 있는 256바이트 필드에 파일 이름 문자열의 끝을 표시합니다.

짧은 답변

실제로,무엇한계?


각주:

  1. 나는 측정을 위해 0.01g의 정확도를 가진 저울을 사용합니다.

  2. 75억 5천만, 이 글을 쓰는 시점에서. 위에서는 이를 10 10 으로 반올림했습니다 .우리는 세기 중반으로 가야 해.

관련 정보