소스 : ZFS, copies, and data protection : Ramblings from Richard's Ranch
ZFS가 블럭 할당을 요청 받았을때 데이타 블럭과 메타 데이타 블럭 할당을 어떻게 하는 것인가에 대한 글입니다.
ZFS는 원래 나왔을 때는 metadata만 redundancy를 가졌는데, nevada 빌드 61부터는 데이타 블럭에 대해서도 redundancy를 가질 수 있도록 했습니다. (리던던시는 같은 블럭의 잉여분을 의미합니다. 장애시 대비를 위한 것입니다.)
즉, 하나의 데이타 블럭이 할당될때는 메타데이타 2블럭과 데이타 블럭 하나가 할당되어지고, 메타 데이타 두개중의 한개는 메타데이타 영역에 나머지 한개는 데이타와 함께 저장을 합니다.
이번 61빌드 이후에는 데이타 블럭도 잉여분을 가질 수 있도록 했는데, 사용자가 지정할 수 있도록 했습니다. 기본값은 1개입니다만 두개로 늘리면 같은 내용의 데이타 블럭이 두개로 늘어납니다. 각 데이타블럭은 메타데이타 블럭과 함께 저장되어야 하므로 메타데이타는 데이타블럭의 개수 + 1개로 결정이 되게 됩니다.
데이타 블럭의 개수가 증가하므로 디스크 사용량이 그만큼 증가하는 것은 너무나 당연하겠죠?
이 데이타 잉여시스템은 볼륨을 제공하는 zpool 단에서 이루어지는 것이 아니라, zfs 단에서 적용되는 것입니다. 따라서, zpool에서 미러링으로 구성했다면, 이중의 중첩된 Data 보호 환경이 구성되는 것이라할 수 있습니다. 미러링과 같은 것을 하지 않은 상태에서 데이타의 무결성을 유지하기 위해서 사용하면 좋을 듯 합니다. 예를 들면, Raid 0(스트라이핑)을 사용할 수 밖에 없으나, 특정 화일 시스템의 데이타는 무결성을 증가하고 싶다면 이 방법을 이용해볼 수 있겠습니다.
ZFS가 블럭 할당을 요청 받았을때 데이타 블럭과 메타 데이타 블럭 할당을 어떻게 하는 것인가에 대한 글입니다.
ZFS는 원래 나왔을 때는 metadata만 redundancy를 가졌는데, nevada 빌드 61부터는 데이타 블럭에 대해서도 redundancy를 가질 수 있도록 했습니다. (리던던시는 같은 블럭의 잉여분을 의미합니다. 장애시 대비를 위한 것입니다.)
즉, 하나의 데이타 블럭이 할당될때는 메타데이타 2블럭과 데이타 블럭 하나가 할당되어지고, 메타 데이타 두개중의 한개는 메타데이타 영역에 나머지 한개는 데이타와 함께 저장을 합니다.
이번 61빌드 이후에는 데이타 블럭도 잉여분을 가질 수 있도록 했는데, 사용자가 지정할 수 있도록 했습니다. 기본값은 1개입니다만 두개로 늘리면 같은 내용의 데이타 블럭이 두개로 늘어납니다. 각 데이타블럭은 메타데이타 블럭과 함께 저장되어야 하므로 메타데이타는 데이타블럭의 개수 + 1개로 결정이 되게 됩니다.
데이타 블럭의 개수가 증가하므로 디스크 사용량이 그만큼 증가하는 것은 너무나 당연하겠죠?
이 데이타 잉여시스템은 볼륨을 제공하는 zpool 단에서 이루어지는 것이 아니라, zfs 단에서 적용되는 것입니다. 따라서, zpool에서 미러링으로 구성했다면, 이중의 중첩된 Data 보호 환경이 구성되는 것이라할 수 있습니다. 미러링과 같은 것을 하지 않은 상태에서 데이타의 무결성을 유지하기 위해서 사용하면 좋을 듯 합니다. 예를 들면, Raid 0(스트라이핑)을 사용할 수 밖에 없으나, 특정 화일 시스템의 데이타는 무결성을 증가하고 싶다면 이 방법을 이용해볼 수 있겠습니다.
