ZFS 정리가 완료되지 않는 이유는 무엇입니까?

ZFS 정리가 완료되지 않는 이유는 무엇입니까?

먼저 제가 실행하고 있는 것부터 시작하겠습니다. Ubuntu 16.10을 실행하는 홈 미디어 서버입니다. 6TB 미러링 드라이브 풀이 절반 정도 찼습니다. 저는 이 시스템을 약 한 달 전에 구축했는데 훌륭하게 작동하고 있습니다. SSD를 부팅 드라이브로 사용하고 앞서 언급한 스토리지 풀을 사용합니다. 나는 이 수영장에서 내가 해야 할 모든 일을 할 수 있었고 모든 것이 멋져 보입니다.

약 한 달 전에 시스템을 구축했을 때 두 드라이브 모두 새 제품이었고 그중 하나의 추가 진동이 조금 궁금했습니다. 나쁘지 않은데 판매자가 무료로 교체해 준다고 해서 스크럽을 해서 빼내고 보내려고 하는데 기다리는 동안 성능이 저하된 상태로 실행됩니다. 백업되지 않은 데이터가 없으므로 크게 걱정하지는 않지만 풀을 종료하고 백업에서 복원하는 것보다 그렇게 하는 것이 더 쉬울 것입니다.

지금 제가 정말로 하고 싶은 일은 스크럽을 실행하고 미러에서 드라이브를 안전하게 분리하는 것입니다. 난 달린다

zpool scrub tank

그런 다음 즉시 실행

zpool status

스크러빙 과정이 진행되는 것을 볼 수 있습니다. 몇 초마다 업데이트를 실행하면 상태가 제대로 업데이트되는 것을 볼 수 있습니다. 약 30초 동안 실행된 후 상태에 더 이상 실행 중이라고 표시되지 않습니다. 그리고 0시간 0분 만에 완료된 마지막 정리 외에는 다른 상태를 본 적이 없습니다. 나에게 이것은 정리가 아직 완료되지 않았음을 의미합니다. 정리가 2.5테라바이트의 정보를 처리하는 데 최소한 몇 시간은 걸리지 않아야 하기 때문입니다.

내가 무엇을 놓치고 있나요?


요청된 정보를 추가하세요:

  pool: Tank
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb  5 00:31:42 2017
config:

        NAME        STATE     READ WRITE CKSUM
        Tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb2    ONLINE       0     0     0
            sdc2    ONLINE       0     0     0

errors: No known data errors

이제 문제가 여전히 존재하는지 확인하기 위해 다시 스크러빙을 시도합니다. 시작한 지 20초 정도 됐는데..

  pool: Tank
 state: ONLINE
  scan: scrub in progress since Fri Feb 10 14:25:12 2017
    62.5M scanned out of 2.97T at 1.08M/s, (scan is slow, no estimated time)
    0 repaired, 0.00% done
config:

    NAME        STATE     READ WRITE CKSUM
    Tank        ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb2    ONLINE       0     0     0
        sdc2    ONLINE       0     0     0

errors: No known data errors

1분쯤 지나서 다시 나타났는데...

  pool: Tank
 state: ONLINE
  scan: scrub repaired 0 in 0h1m with 0 errors on Fri Feb 10 14:27:01 2017
config:

    NAME        STATE     READ WRITE CKSUM
    Tank        ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb2    ONLINE       0     0     0
        sdc2    ONLINE       0     0     0

errors: No known data errors

2017년 2월 16일 정보 추가 수정

"시끄러운" 드라이브를 다시 가져올 시간이 없어서 꺼냈습니다. 나는 (시스템이 시작될 때) 플러그를 뽑는 것 외에는 아무것도 하지 않았습니다. 현재 예상대로 성능이 저하된 상태이기는 하지만 모든 것이 계속해서 정상적으로 실행됩니다. 나는 그 일을 시작한 이후로 내 경험을 여기에 계속 기록해야겠다고 생각했습니다. 이 문제를 겪는 사람은 아무도 없는 것 같습니다. 같은 상황에 처한 다른 사람을 온라인에서 찾을 수 없는 것 같습니다. 운이 좋은 날. 교체 드라이브를 구입하여 다시 실버 처리하면 어떻게 되는지 살펴보겠습니다. 누가 알겠습니까... 어쩌면 데이터 신이 나에게 자비를 베풀어 드라이브를 교체하기만 하면 문제가 저절로 해결될 수도 있습니다. :/ 아래는 드라이브 연결을 끊은 후의 출력입니다.

  pool: Tank
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: scrub repaired 0 in 0h1m with 0 errors on Sun Feb 12 00:24:38 2017
config:

        NAME        STATE     READ WRITE CKSUM
        Tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sdb2    ONLINE       0     0     0
            sdc2    UNAVAIL      0     0     0

errors: No known data errors

2017년 3월 29일 정보 추가 수정

root@NAS:~# zpool status
  pool: Tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: resilvered 525M in 0h3m with 0 errors on Wed Mar 29 14:28:46 2017
config:

        NAME        STATE     READ WRITE CKSUM
        Tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb2    ONLINE       0     0     0
            sdc     ONLINE       0     0   732

errors: No known data errors

문제에 대한 또 다른 단서가 있을까요? sdc 파티션을 보세요...

root@NAS:/dev# parted --list
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size    File system     Name                  Flags
 1      1049kB  538MB  537MB   fat32           EFI System Partition  boot, esp
 2      538MB   233GB  232GB   ext4
 3      233GB   250GB  17.1GB  linux-swap(v1)


Warning: Not all of the space available to /dev/sdb appears to be used, you can
fix the GPT to use all of the space (an extra 7 blocks) or continue with the
current setting?
Fix/Ignore? i
Model: ATA HGST HUH728060AL (scsi)
Disk /dev/sdb: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      2097kB  2150MB  2147MB
 2      2150MB  6001GB  5999GB  zfs


Model: ATA HGST HUH728060AL (scsi)
Disk /dev/sdc: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  6001GB  6001GB  zfs          zfs-802af6a53a6d8383
 9      6001GB  6001GB  8389kB

2017년 4월 13일 정보 추가 수정

네, 저는 몇 달 동안 이 문제를 해결하려고 노력해 왔습니다. :/

먼저 내보내기/가져오기 드라이브 문자를 변경한 후 sdb는 sdc, sdc는 sdd가 된다는 점에 유의하시기 바랍니다.

문제를 발견한 것 같아요, 해결 방법에 대한 조언을 듣고 싶습니다. "sudo fdisk -l"을 실행했을 때 마침내 문제를 발견했습니다. 관련 클립은 이렇습니다...

Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7127FE7D-E061-11E6-BD1F-3497F600DDAF

 Device     Start        End       Sectors    Size    Type
/dev/sdc1   4096       4198399     4194304     2G     FreeBSD swap
/dev/sdc2  4198400   11721043967 11716845568  5.5T    FreeBSD ZFS

...

Disk /dev/sdd: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E799A1D5-F9B7-C843-AB62-AADC9B0A2180

Device        Start           End         Sectors    Size    Type
/dev/sdd1      2048       11721027583   11721025536  5.5T    Solaris /usr & Apple ZFS
/dev/sdd9  11721027584    11721043967      16384      8M     Solaris reserved 1

참고: 이미지는 원래 FreeNAS(FreeBSD)에서 생성되었습니다. sdc에는 드라이브 시작 부분에 2G 스왑이 있습니다. sdd는 Ubuntu에서 생성되었으며 어떤 이유로 드라이브 끝에 8M 스왑 공간이 할당되었습니다.

이제 문제가 손상된 드라이브일까봐 두려워서 sdd를 오프라인으로 전환하고 거기에서 배드 블록을 실행했습니다. 그러면 모든 정보가 삭제됩니다. 좋은 소식은 드라이브가 양호하고 불량 블록이 없다는 것입니다. 그러면 파티션도 빈 상태로 재설정됩니다.

나에게는 두 가지 선택이 있습니다. 1.) sdd의 파티션을 작업 드라이브(sdc)와 수동으로 일치시켜 보십시오. 비록 zfs가 zpool 교체를 수행하여 자동으로 이 작업을 수행한다고 생각하지만 어쩌면 이는 단지 시간 낭비일 수도 있습니다. 2.) 두 드라이브를 모두 지우고 처음부터 시작하여 새 이미지를 생성하고 기본 Ubuntu 풀로 만들 수 있도록 데이터를 백업했습니다.

너무 과한 생각일지도 모르지만, 더 큰 피해와 회복의 위험이 있다고 생각합니다. 미러되지 않은 디스크에만 백업된 양호한 데이터를 삭제한 다음 새로 생성된 풀에 다시 동기화해야 합니다. 참고로 rsync를 사용하여 백업을 생성했는데 동일한 컴퓨터에 있습니다. 모든 데이터를 수용하기 위해 중복 없이 3개의 드라이브를 제거해야 했습니다. 이렇게 데이터를 정리하지 못한 채 옮기게 되면 제가 알지 못하는 피해를 입을 수도 있다는 걱정도 듭니다.

누구든지 어떤 제안이 있습니까? 감사해요!

관련 정보