zpool이 Ubuntu Xenial에서 / dev / disk / by-id를 사용하도록 설정

Ubuntu 16.04 Xenial에서 번들로 제공되는 OpenZFS를 사용 해보고 있습니다.

풀을 만들 때 항상 복원력을 위해 드라이브를 직렬 /dev/disk/by-id/(또는 /dev/disk/gptFreeBSD)로 참조합니다 . /dev머신이 재부팅 될 때 드라이브가 항상 같은 순서로 정렬되는 것은 아니며 머신에 다른 드라이브가있는 경우 풀이 올바르게 마운트되지 않을 수 있습니다.

예를 들어 zpool status14.04 상자 에서 실행 하면 다음과 같이됩니다.

NAME                                  STATE     READ WRITE CKSUM
tank                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0

그러나 16.04에 다음과 같이 새 풀을 만들면 (약어) :

zpool create pool raidz \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..]

나는 이것을 가지고 얻는다 zpool status:

NAME        STATE     READ WRITE CKSUM
tank        ONLINE       0     0     0
  raidz1-0  ONLINE       0     0     0
    sdf     ONLINE       0     0     0
    sde     ONLINE       0     0     0
    sdd     ONLINE       0     0     0
    sda     ONLINE       0     0     0

zpool이 심볼릭 링크를 참조하지 않고 심볼릭 링크를 따르는 것처럼 보입니다.

풀을 만들 때 16.04의 zpool이 내 드라이브 참조를 준수하도록하는 방법이 있습니까? 또는 대안으로, 여기에서하는 일이 잘못되었다고 생각합니까?

업데이트 : 해결 방법

나는 스레드 발견 해결 방법을 제안 Github에서에 zfsonlinux를 들어. /dev/sdX먼저 장치를 사용 하여 zpool을 만든 후 다음을 수행하십시오.

$ sudo zpool export tank
$ sudo zpool import -d /dev/disk/by-id -aN

나는 zpool create가능하다면 초기에 이것을 할 수 있기를 여전히 선호한다 .

ubuntu zfs

— 루벤 샤드
소스

어떻게 만드는지 중요하지 않습니다. / dev / sd로 되 돌리면? 장치 이름은 zfs export및 zfs import -d작동합니다. BTW, 당신이 정말로 모든 바이트 공간을 필요로 하지 않는 한 , raidz보다는 2 개의 미러링 된 쌍을 사용하십시오. raidz의 성능은 raid-5보다 우수하지만 raid-10 또는 zfs 미러 쌍보다 훨씬 나쁩니다. 미러 쌍으로 구성된 풀을 확장하는 것이 더 쉽고 한 번에 두 개의 디스크 만 추가하면됩니다. raidz를 사용하면 각 드라이브를 더 큰 드라이브로 교체해야합니다. 모든 드라이브를 교체 한 경우에만 수영장에 더 많은 공간이 있습니다.

— cas

나는 아직도 약간의 raid-z 수영장을 가지고 있으며 후회했다. 교체 디스크를 구입할 여유가 있으면 미러링 된 쌍으로 새 풀을 만들고 zfs send데이터를 새 풀로 복사 하는 데 사용 합니다. 실제로, raid-z는 한 번에 6 개 또는 8 개의 트랜스 코딩 작업을 실행하지 않는 한 성능이 중요하지 않은 mythtv 상자에 적합합니다. 내 /home 디렉토리가 있는 풀에서 미러 쌍으로 변경하면 매우 눈에 .니다.

— cas

ZIL의 미러링은 전력 손실을 막기 위해 대용량 커패시터가 장착 된 고가의 SSD가 아닌 일반 저렴한 SSD를 사용하여 벗어날 수 있습니다. IMO, ZIL 미러링은 어떤 종류의 SSD에 관계없이 선택 사항 이 아닙니다 . ZIL이 죽으면 아직 기록되지 않은 모든 데이터가 손실되고 풀이 손상 될 수 있습니다. L2ARC에 관해서는, 나는 특별히 그것들을 미러링 하지 말라고 말했다 ...

— cas

:) BTW, ZIL을 미러링하는 이유를 설명했을 때 뇌가 제대로 작동하지 않았습니다. 그것은 전원 손실을 막지 않아야합니다. 완전한 말도 안되며 결코 말하지 않아야합니다. ZIL 드라이브의 고장을 방지해야합니다. 즉, ZIL의 raid-1 미러입니다. 합리적인 가격의 SSD 두 개는 일반적으로 하나의 매우 비싼 것보다 낫습니다 (더 비싼 SSD가 PCI-e 대 SATA와 같이 훨씬 빠른 인터페이스를 가지고 있지 않는 한). 그리고 UPS는 필수적입니다.

— cas

@cas Mirrored ZIL 은 예기치 않은 종료 와 동시에 SLOG 장치 오류로부터 보호합니다 . 정상적인 작업에서 ZIL은 쓰기 전용이며 영구 저장소에 대한 쓰기는 RAM (ARC)에서 이루어집니다. 시스템이 예기치 않게 종료되면 의도 로그 (ZIL, SLOG)를 사용하여 중단 된 쓰기를 완료합니다. 예기치 않은 종료가 SLOG 장치의 장애와 일치하는 경우에만 인터럽트 된 쓰기를 복구하기 위해 중복 SLOG가 필요합니다. 대부분의 비 서버 (및 많은 서버) 워크로드의 경우 ZIL이 실제로 동기 쓰기 작업 만 수행하므로 SLOG는 과도합니다.

— CVn

가끔씩 zpool import -d /dev/disk/by-id작동하지 않습니다.

둘 이상의 환경에서 이것을 발견했습니다. 마법 논리를 수행하고 물리적으로 연결된 ZFS 장치를 보여주는 것 외에도 기본적으로 다음과 같은 가져 오기 스크립트가 있습니다.

zpool import -d /dev/disk/by-id POOL
zpool export POOL
zpool import POOL

-d스위치 없이도 두 번째 로, 명시 적 명령으로 처음이 아니더라도 장치 ID로 가져옵니다.

몇 주 또는 몇 달 동안 (1 년 또는 2 년 전) ZFS 버그로 인한 것일 수 있으며 더 이상 필요하지 않습니다. 버그 보고서를 제출해야한다고 생각했지만 해결하기가 쉽지 않았습니다.

— 짐
소스

이 스레드가 부실하다는 것을 알고 있지만 대답이 있습니다. 가져온 후 캐시 파일을 업데이트해야합니다. 이 예는 캐시 파일의 기본 위치를 보여줍니다.

$> sudo zpool export POOL
$> sudo zpool import -d /dev/disk/by-id POOL
$> sudo zpool import -c /etc/zfs/zpool.cache
$> sudo zpool status POOL
NAME                                  STATE     READ WRITE CKSUM
POOL                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0

— 스티브 오
소스