[강석기 과학카페] 한때 언어 유전자로 불렸던 FOXP2 이야기
    https://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=105&oid=584&aid=0000001680&rc=N

SSD comparison: Crucial MX500 vs. BX300
    https://www.datenreise.de/en/ssd-comparison-crucial-mx-vs-bx/

ZFS 오류 복구 3 (정확히는 4)

시게이트 ST3000DM001 (/dev/sdc)가 또 하나 맛이 갔다.
지난번과 마찬가지로 TOSHIBA DT01ACA300 모델로 교체했다.
이 모델로 바꾸는 이유는 [1] 7200 RPM 3TB 모델 가운데 제일 싸고
[2] 같은 모델이 그동안 별 문제를 일으키지 않고 잘 동작중이어서다.

교체 과정은 전과 같음.

시게이트 ST3000DM001 는 그동안 여섯 개인가 죽고 이제 두 개 남았다.

오래전부터 느껴오던 문제가 있다.

굿네이버스 등 여러 단체들을 통해 해외 어린이 정기 후원을 하는 사람들이 많고,
자신의 후원 이야기를 담은 글을 블로그 등에 올리는 경우도 많다.
대개는 후원을 하게 된 개인적인 동기, 후원의 느낌, 자신만의 의미부여 소회 등을
기록하고 싶은 마음에 올리는 글들인데, 그 취지는 충분히 공감하고 보기에도 좋지만
그런 글의 상당수가 아이의 신상정보를 지나치게 드러내고 있는 점만은 문제가 있다고 생각한다.

아이의 사진은 물론이고 신상정보가 정리된 카드까지 통째로 찍어서 올리곤 하는데
아이의 입장에서 이런 행위가 달가울 리는 없을 것이다.

후원자는 후원자로써 아이를 도울 뿐, 아이에 대해 어떤 권리를 가지는 것은 아니다.
아이의 개인정보는 후원자에게만 특별히 제공된 것이며 소중히 보호받아야 한다.

후원자라고 해서 아이의 개인정보를 함부로 공개하는 행위는 삼가도록
후원중개기관에서 배포하는 개인정보 카드에 눈에 잘 띄게 적어주면 좋겠다.

ZFS 오류 복구 3 (정확히는 4)

시게이트 ST3000DM001 (/dev/sdb)가 하나 더 맛이 갔다.
지난번까지는 HGST HDN724030ALE640로 교체했지만,
이번에는 TOSHIBA DT01ACA300 모델로 교체했다.
과정은 전과 같음.

# Here Strings
$ cat <<<asdf
asdf

# Process substitution
$ cat < <(echo asdf)
asdf
$ cat <(echo asdf)
asdf

$ echo asdf | cat
asdf

하드 디스크 6개 짜리 RAID-Z2 볼륨에서 네 번째로 디스크 문제가 생겼다.
2013년 4월에 Seagate Barracuda ST3000DM001 모델 6개로 구성했는데
만 2년이 지난 (보증기간이 딱 지난) 2015년 6월부터 하나씩 문제가 생기더니 최근 1년 사이에 4개째다.

처음 두 개는 같은 모델 여분의 디스크로 교체하다가 뭔가 아니다 싶어서
이후부터는 다른 모델로 교체했다 (HGST HDN724030ALE640).

오늘 생긴 문제는 디스크가 죽는 수준은 아니고
배드섹터 전단계의 섹터가 8개 나왔다는 SMART 경고가 메일로 날아온 것이었다.

접속해서 살펴본 SMART 정보는 아래와 같았다.



경험상 이 모델은 믿을 수 없으므로, 문제의 소지가 발견된 순간 바로 교체했다.

(이 모델의 유독 높은 오류발생률은 이미 유명하다.
 CSI: Backblaze – Dissecting 3TB Drive Failure
    https://www.backblaze.com/blog/3tb-hard-drive-failure/ )



헌 디스크 분리하고, 새 디스크 다는 과정에서 생긴 dmesg 로그는 아래와 같았다.
훌륭하게 된 건지는 모르겠고, 리눅스 가동중인 상태에서도 교체는 그럭저럭 가능했다.

그나마 4칸짜리 하드디스크랙(앤디코 하드랙 EasySTOR 340SS)을 설치해뒀기에 가능한 일이었다.
전에 PC 케이스의 내장 HDD 자리에 달려있던 디스크가 죽었을때는 어쩔 수 없이 전원 끄고 작업했다.

업무상 잡용도로 혼자 쓰는 우분투 서버를 운영한다.
루트파일시스템으로 btrfs 파일시스템을 쓰고 잡 백업 용도로 zfs raid-z2 볼륨을 구성해 쓴다.

처음엔 Ubuntu 12.04를 설치해서 한두해 쓰다가 몇 달 전에 14.04로 업그레이드했고,
이번에 다시 16.04로 업그레이드했다.

14.04 LTS -> 16.04 LTS 업그레이드하며 겪은 일을 생각나는대로 간단히 적어둔다.

업그레이드는 $ sudo do-release-upgrade -d 식으로 했다.
아직 14.04 -> 16.04 업그레이드가 정식으로 오픈되지 않은 상태이므로 -d 옵션을 줘야 했다.
운영중인 시스템에 이렇게 실험적인 업그레이드를 시도한 것은 btrfs snapshot 기능을 믿었기 때문이다.

btrfs snapshot을 이용한 안전한 do-release-upgrade 실험
    http://chanik.egloos.com/4099097

업그레이드는 위 글에 나온 식으로 @_16.04, @home_16.04 snapshot을 만들고
그 스냅샷으로 부팅한 상태에서 진행했다. 하다가 꼬이면 그냥 스냅샷을 날려버리고 원복할 생각이었다.

12.04 LTS -> 14.04 LTS 때와 달라진 점은 Ubuntu 16.04 LTS가 zfs를 커널 자체에서 지원하게 된 것이다.
14.04에서 http://zfsonlinux.org/ 리포로부터 설치해서 쓰던 zfs 모듈이 16.04에서는 커널 자체모듈로 대체되고,
zfsutils-linux 패키지도 http://zfsonlinux.org/ 리포의 것이 아닌, 우분투 자체 리포의 것을 써야 했다.

업그레이드 전에는 http://zfsonlinux.org/ 리포를 꺼야 했고,
업그레이드 뒤에는 자동으로 zfs 볼륨이 올라오지 않는 현상 때문에 아래와 같이
zfsutils-linux 패키지를 자체 리포의 것으로 교체해야 했다.

ZFS Pools not mounted 16.04
    http://askubuntu.com/questions/768179/zfs-pools-not-mounted-16-04



그리고, remove 할 때 zfs-auto-snapshot 패키지도 함께 사라져서 아래와 같이 다시 설치했다.



그냥 설치했다가 "/bin/sh: 1: zfs-auto-snapshot: not found" 오류를 겪고 나서,
make install 전에 etc/zfs-auto-snapshot.cron.frequent 스크립트를 아래와 같이 수정해야 했다.



12.04 LTS -> 14.04 LTS 때와 달라진 점 또 한 가지는,
16.04 LTS에서는 python 2를 없애버려도 된다는 것이다.
아래와 같이 했다.

Ubuntu 16.04 LTS 파이썬2 제거
    http://chanik.egloos.com/4112679


끝으로, PostgreSQL 버전이 9.3 -> 9.5로 바뀌었으므로 데이터를 새 버전으로 이전해야 했다.
지난 번 12.04 LTS -> 14.04 LTS 업그레이드때도 해야 했던 작업이었고 아래 글을 참조했다.

Upgrading PostgreSQL 9.1 to 9.3 in Ubuntu
    http://nixmash.com/postgresql/upgrading-postgresql-9-1-to-9-3-in-ubuntu/

위 글의 명령대로 하면 너무 느리기도 하고 중간에 오류도 생겨서, 아래와 같이 좀 수정된 명령을 썼다.
( 그리고, 내가 관리하는 DB는 테이블이 너무 많고 데이터도 많아서 변환중에 오류를 뿜었다.
 /etc/postgresql/9.3/main/postgresql.conf 을 임시로 수정해서
 max_locks_per_transaction = 640 정도로 임시설정하고 다시 변환해야 했다)


ㅇ "-m upgrade" means using pg_upgrade instead of pg_dump & pg_restore,
ㅇ "-k" means using hard links instead of file copying (so it can be used only if old DB and new DB is in the same partition). Manual page states that "-k" is merely passed to the pg_upgrade comand.

14.04 -> 16.04 로 do-release-upgrade -d 방식으로 업그레이드하면
python2와 python3가 공존하는 형태로 설치된다.

python2를 없애고 python3만 남겨 쓰기 위해 아래와 같이 했다.


https://wiki.ubuntu.com/XenialXerus/ReleaseNotes



http://askubuntu.com/questions/761106/how-to-remove-python-2-in-16-04


이 상태에서 python을 실행하면 조용히 python3가 실행되는 것이 아니고 무슨 헛소리가 나온다.
아래와 같이 해 줘야 비로소 python 명령으로 자연스럽게 python3을 실행할 수 있다.

https://linuxconfig.org/how-to-change-from-default-to-alternative-python-version-on-debian-linux

# update-alternatives --install /usr/bin/python python /usr/bin/python3.5 1

500GB 하드디스크 두 개에 Btrfs RAID1 볼륨으로 루트파일시스템이 설치되어 있는 상태인데
이 부트파티션을 다른 테스트PC로 간단히 복제해 쓰고 싶어서 했던 작업 기록.
작업 며칠 뒤에 편집하고 재구성한 것이라서 기록이 좀 미비하다.
설치되어 있던 배포판은 CentOS-7.

볼륨 구성은 아래와 같다.


sda1은 원래는 /boot 용도였지만 지금은 쓰지 않는 파티션.
sda2는 sdb1과 함께 Btrfs RAID1 볼륨. CentOS-7 설치된 상태.
sda3은 SWAP 파티션.



#
# 원본 Btrfs 파티션 마운트
#



#
# 각 서브볼륨에 대해 snapshot 을 작성하고, snapshot 들을 읽기전용으로 변경
# 읽기전용이 아니면 send 시도할때 오류가 생긴다.
#



#
# - 새 하드디스크 /dev/sdc 연결하고 파티션테이블 레이아웃 복제 (새 디스크도 500GB 짜리)
# - /dev/sdc3에 SWAP 파티션 생성
# - /dev/sdc2에 Btrfs 파일시스템 생성 (원본은 RAID1볼륨이지만 새 볼륨은 단일디스크 볼륨)
#



#
# 새로 만든 Btrfs 파티션을 마운트하고 마운트 디렉토리로 이동
#



#
# 원본 Btrfs 서브볼륨들에 대해 만들어둔 읽기전용 스냅샷을 하나씩 send 하고
# 새로 만든 Btrfs 파티션에서 receive.
#



#
# 이제 새 디스크의 새 Btrfs 파티션에 서브볼륨들이 복제된 상태다.
# 원본은 RAID1 볼륨이었으나 새 볼륨은 단일디스크 볼륨이며, 내용물은 동일한 상태가 된다.
# 각 서브볼륨 이름을 변경하고, 읽기전용 속성도 풀어준다.
#



#
# 새 볼륨의 boot/grub2/grub.cfg 파일 적당히 편집하고
# chroot해서 grub2-install 등도 해 준다.
# 이제 새 디스크에 부트파티션의 Btrfs 볼륨이 복제되었고 grub2도 설치되었으므로
# 새 PC로 가져가서 부팅용으로 쓰면 된다.
#
# 해보니 일단 부팅은 잘 되는데,
# 일부 패키지들의 실행파일 setuid 비트가 제대로 옮겨지지 않아서 자잘한 문제가 생겼다.
# 이를테면, hostnamectl로 기기명을 변경해도 재부팅하면 다시 원래대로 되돌아가버린다든지..
#
# 아래 명령으로 전체 패키지를 재설치시켜서 해결했다. 물론 시간이 좀 걸린다.
#