왜 나는 카카오톡을 쓰지 않는가

첫번째 이유는 카카오톡(이하 줄여서 '카톡'이라 하겠다)을 구동할 변변한 안드로이드 단말기가 없기 때문이고, 두번째 이유는 일상생활이나 업무에 방해가 된다고 생각하기 때문이다.

원래 작년에 모토롤라의 아트릭스를 구입해서 쓰고 있었으나, 이를 딸에게 주고 나니 마땅한  단말기가 없는 상태가 되고 말았다. 피처폰을 잠시 쓰다가 지금은 윈도우 모바일 6.5가 설치된 옴니아팝을 쓰고 있다. 카톡을 설치할 수 없는 단말기이다. 화면도 작고, 인터넷 브라우징도 느리고 불편하다. 그야말로 음성통화+문자 메시지+전자메일 확인이라는 단말기 본연의 목적으로 아주 잘 활용하고 있다. 멜론 평생 무료라는 점도 매력이고, 배터리도 삼일씩 충전을 하지 않고 다녀도 될 정도이다.

중고로 구입한 SKY 미라크를 갖고 있기는 하다. 가끔 여기에 USIM을 바꾸어 끼워서 사용할 때가 있다. 외출을 해서 사진만 찍으면 자동으로 '구글+'로 업로드되고, 모든 면에서 옴니아팝보다 못한 것이 없다(화면이 좀 어둡고 배터리 소모는 빠르다는 것을 제외하면). 그런데 문제는 여기에 있다. 미라크를 쓰게 되면, 쓸데없이 휴대폰을 만지작거리는 일이 많아진다는 것이다. 아무리 성능이 좋아졌다 해도 휴대폰은 휴대폰이다. 그 작고 불편한 휴대폰의 화면으로 괜히 웹 브라우저를 통해 바깥 세상에 무슨 일이 일어났는지 봐야 할 것 같고, 카카오톡 친구 리스트도 괜히 한번 훑어 보면서 바뀐 사진이나 인사말이 없는지도 봐야 할 것 같고...

카카오톡이 세상에 나온 이후로 아줌마들의 수다 문화도 많이 바뀌었다. 아내도 카톡을 보면서 누구 엄마네 가족이 해외 여행을 다녀 왔는지, 무슨 음식을 먹었는지 등의 소소한 일상을 '엿보기'하면서 즐거워 한다. 만날 약속을 정하기도 하고, 심각한 대화를 나누기도 한다. 필요한 사람은 필요한 대로 쓰는 것이다.

내가 아는 어떤 사람은 스팸 문자 메시지가 하도 많이 와서 며칠에 한번 확인할 정도이고, 이런 지격이니 음성 통화나 카톡 메시지가 아니면 연락을 하기 어렵다. 반면 나는 광고성 문자메시지에 대해서는 일일이 수신 거부 전화를 하고, 또 사적으로 쓰는 전자메일로 광고가 날아오는 경우 철저하게 unsubscribe를 하고 있다. 덕분에 집중력을 흩뜨리는 광고 메일이 많이 줄었다.

회원 탈퇴를 했는데도 회원에 가입이 되어 있고 광고 메일 수신에 동의했다면서 끝없이 메일을 보내는 인터넷 가구 판매 사이트가 있다. 여기는 내가 언제 한번 직접 전화를 해서 응징을 하리라.

그렇다. 사람마다 사는 방식이 다르다. 휴대폰, 그리고 스마트폰이 생활을 조금 편리하게 해 준 것은 맞지만, 바로 곁에서 지금 대하고 있는 사람에게 집중을 하지 못하게 한다면 무슨 소용이 있겠는가? 그래서 나는 카톡을 쓰지 않는 것이다.

예전에 네이버 블로그에 이런 취지의 글을 올렸더니, 어떤 사람이 이런 덧글을 붙였다.

"님은 사회 부적응자 외톨이로군요. 불쌍합니다"

세상에는 참 별의 별 인간이 다 있다.

우분투 64비트에서 리눅스용 한/글 설치하기

작년에 리눅스용 한/글 2008을 구입하여 설치도 못한 상태로 한동안 잊고 있었다. 사무실을 정리하다가 설치 매체를 발견하고는 생각이 나서 잠깐 웹 검색을 해 보니 많은 어려움 끝에 드디어 설치에 성공한 사람들의 글이 보인다.

Ubuntu 12.04LTS(64bit)에서의 HWP2008 for Linux 완벽설치

참으로 멋진 사람들이다!

참고로 다음의 글타래에 윗 글을 비롯하여 우분투에서 리눅스용 한/글을 설치하게 위해 많은 노력을 한 사람들의 흔적이 고스란히 남아 있다!

우분투 12.04 (ubuntu 12.04)에서 한글 2008 설치하기(쿠분투 12.04 동일)

나도 언젠가는 성공해 보리라! 그 전에 데스크탑 컴퓨터의 OS부터 우분투 10.04->12.x로 빨리 올려야 되는데...

de novo assembly의 지표 - N50과 L50

de novo assembly의 결과 수치 중에서 연구자가 가장 민감하게 받아들이는 것은 바로 contig들의 숫자와 길이에 관한 것이다. contig의 수는 매우 명백하게 받아들일 수 있다(물론 길이에 대해서 cutoff를 적용할 수는 있다). 그런데 '길이'는 조금 다르다.

물론 total length도 중요하다 :) 이 값은 read가 추가될수록 유전체의 크기에 근접하는 것이 당연하다. 요즘은 거대 genome을 시퀀싱하는 경우가 아니라면 한번에 목표한 수량 이상의 데이터가 생산되므로, 일 또는 주 단위로 생산된 데이터를 추가하여 합체한 뒤 이상한 행태를 보이지 않는지 추적할 필요가 없어져 버렸다.

contig의 평균 길이는 계산하기도 쉽고 이해하기도 쉽다. 하지만 짧은 contig가 유난히 많거나, 혹은 gap closing이 꾸준히 진행되어서 큰 contig가 많다면 단순히 산술적으로 계산한 평균 길이는 편향된 값을 나타내기 쉽다. 그래서 고안된 수치가 바로 N50 statistic이다.

N50을 계산하는 방법은 별로 어렵지 않다.

(1) 서열들을 크기 순으로 오름차순 정렬을 한다. 어느 contig를 시발점으로 하여 큰 contig들의 길이를 전부 더했을 때, total length의 50%와 같거나 넘는 순간 바로 그 contig의 길이를 N50이라 정의하였다. Broad Institute의 정의를 따르자면 weighted median 정도가 될 것이다.

N50은 평균 길이와는 달리 매우 현실적인 숫자이다. 1 kb와 11 kb의 서열이 하나씩 있을 때, 평균 길이는 6 kb가 된다. 그러나 우리의 서열 모음에는 6 kb짜리 서열은 없다. 이에 반하여 N50은 서열 모음 내에 있는 특정 서열의 길이가 된다(여기에는 약간 다른 의견이 있기도 하다).

그런데 최근에는 N50을 다른 의미로 쓰는 문헌이 보이기 시작한다. N50을 '전체 길이의 합 50%를 초과하게 만드는 서열의 수'로, 그리고 고전적인 N50을 대신하여 L50이라는 용어를 쓰는 것이다. 아마도 N은 숫자, L은 길이라고 생각을 해서 그런 것으로 보인다.

Broad Institute에서 제시한 N50의 아주 기본적인 정의에 대해서 다시 알아보자.

(2) Given a set of sequences of varying lengths, the N50 length is defined as the length N for which 50% of all bases in the sequences are in a sequence of length L < N.

잠깐, 이것은 (1)과는 계산 방향이 반대 아닌가. N50보다 작은 contig의 합이 전체의 50%라는 말이다. 실용적으로는 별 상관이 없다. 단, N25나 N75처럼 50%가 아닌 숫자에 대해서 논할 때에는 합산의 방향이 문제가 된다.

다음은 E. Lander의 논문에 의한 정의이다. 이는 (1)과 별반 다르지 않다.


More exactly, the N50 length is defined such that half of the nucleotides reside in contigs or scaffolds having a length of at least N50 length.

LVM 유지 보수 - 정말 HDD를 교체해야 되겠다!

꼭 일주일만에 또다시 LVM으로 잡은 논리 볼륨에서 오류가 발생하고 말았다. 재부팅을 해 보니 여섯번째 드라이브(바로 지난 주에 I/O error가 났던)의 인식이 신통치 않다. 부팅을 하면서 자동으로 디스크를 체크하는데 드디어 fsck를 매뉴얼로 실시하라는 메시지가 나왔다.

그래, 해 보지 뭐. 시간은 좀 걸리겠지만.

fsck -y <논리 볼륨명>

inode가 어쩌고 저쩌고.... 한참을 걸려 몇군데를 고치는가 싶더니 정상적으로 체크와 수정이 끝났다. 재부팅을 하니 무사히 시스템이 올라오고 드라이브가 마운트되었다. 또다시 에러가 발생하지 말라는 법이 없으니, 용의자 드라이브를 교체하는 것이 바람직할 것으로 생각한다.

하지만 LVM으로 묶은 드라이브 중 하나를 교체하는 것은 그렇게 심플하지 않다. 가장 바람직한 방법은 물리 볼륨을 하나 추가한 뒤, 에러가 빈발하는 드라이브를 제거하면 될 것이다. GUI tool(system-config-lvm)을 쓰면 간단히 해결될 것이다. 실제로 GUI tool을 실행시켜서 특정 드라이브를 제거하려고 하면 여유 공간이 없어서 진행하지 못한다는 메시지가 나온다. 100% 확신할 수는 없지만, 추가 물리 볼륨을 먼저 넣은 다음 진행해야 할 것으로 보인다.

그런데 드라이브를 꽂을 베이가 더 이상 없다. 이런 상황에서는 어떻게 해야 될까? 검색을 해 보니 pvmove로 제거할 드라이브의 데이터를 다른 드라이브로 옮기라고 한다. 그런 뒤 pvdisplay로 해당 드라이브가 사용되지 않음을 확인한 다음,

빼낼 드라이브의 크기만큼(혹은 그보다 조금 더) 논리 볼륨의 크기를 적절히 줄인 다음, 해당하는 물리 볼륨을 제거하면 될 것이다. 이제 비로소 vgreduce로 논리 볼륨에서 물리 볼륨을제거할 수 있게 되었다.

# pvmove /dev/sdf1
# pvdisplay /dev/sdf1
# vgreduce <볼륨 그룹> /dev/sdf1

단, 이상의 명령어는 아직 실행에 옮겨본 것은 아니다. GUI tool이 편한 것은 사실이지만, 디스크 관리 작업과 같이 시간이 많이 걸리는 명령을 실행할 경우 제대로 진행 중인지 혹은 에러가 발생한 것인지 알기 어렵다는 것이 문제이다. 그나마 CLI는 대부분의 경우 메시지가 나오기라도 하니까. 이상과 같이 디스크 교체가 아니라 문제가 발생한 디스크만 쏙 빼내고 싶은 경우 정확히 어떻게 해야 할까?

만일 다음에 LVM을 새로 설치하게 된다면 선형/스트라이프/미러 중 용도에 맞는 것을 골라서 설치하도록 하자. 스냅샷에 대해서도 공부를 해야 하는데...

우분투에서 LVM 관리는 또 다르지 않을까? 외국어로 친다면 2개 국어를 해야 할 형편이다. 우분투, 그리고 레드햇 계열(CentOS).

참고 문헌: 레드햇 LVM 관리자 가이드

메모리 이야기 - ECC UDIMM & RDIMM

서버용 메인보드에는 고가의 ECC(error checking & correction) 메모리가 쓰이는 것으로 알고 있다. 이는 오류를 검출하는 것에 그치는 것이 아니라 정정까지 한다는 측면에서 패리티 검사와는 다르다고 한다.

ECC 기능이 실제로 어떻게 구현되는지에 대해서는 자료를 읽어도 잘 모르겠고, 다만 실제 제품으로는 UDIMM(unbuffered DIMM)과 RDIMM(registerd  DIMM)이 있다. 그리고 이 둘은 자유롭게 호환되지는 않는다.

아주 기본에 속하는 사항이지만 참고로 말하자면 DIMM(dual in-line memory module)은 실제 보드의 메모리 소켓에 꽂게 되어 있는 메모리 모듈을 말한다. 여기에는 72핀이니 168핀이니 하는 외형상의 구별이 있고, 또한 속도와 관련하여 DDR이니 DDR2니 하는 여러 용어가 있다. SDRAM(synchronous dynamic RAM)은 요즘 개인용 컴퓨터나 워크스테이션에 쓰이는 DIMM의 가장 보편적인 형태라 보면 되겠다.

Unbuffered ECC 메모리에서는 메모리와 관련된 명령이 메모리 모듈로 직접 전달된다. 그러나 registered ECC 메모리에서는 우선 메모리 뱅크의 레지스터로 전달된 다음 비로소 메모리 모듈로 향한다는 것이 다르다.

내가 쓰고 있는 두 종류의 '서버급' 메인보드의 매뉴얼을 펼쳐보도록 하겠다.

• Tyan S7002(E5620 x 2 @2.4 GHz): DDR3 800/1066/1333 RDIMM, UDIMM, up to 64 GB
• Supermicro X8SAX(E5520 @2.27 GHz): DDR3 SDRAM for unbuffered ECC or non ECC 1366/1066/800 MHz memory

Tyan 서버를 2009년 구입할 때, 방열판이 달린 4GB DIMM(삼성 M393B5170EH1-CH9)을 2개 달았었다. 이를 2012년에 업그레이드하면서 8 MB 메모리 8개를 꽉 채웠는데, 여기에서 빼낸 4 GB 메모리를 다른 보드에 도대체 쓸 수가 없었다. 왜냐하면 이것은 바로 registered DIMM이기 때문이다. 따라서 2012년에 따로 구입해서 조립한 Supermicro 보드나 다른 데스크탑에도 끼우지 못하고 그냥 서랍 속에 방치되고 있다.

Supermicro 보드는 Tyan 서버에 꽂힌 CPU를 E5520 1개에서 E5620 2개로 업그레이드하면서 남은 E5520을 활용하기 위해 궁여지책으로 구입하게 된 것이다. LGA1366 소켓의 제온 CPU를 꽂을 수 있는 보드를 찾는 것이 꽤 어려웠었다.

요즘의 서버 메인보드는 친절하게도 ECC 메모리와 일반 메모리 모두 사용 가능하게 제조되는 편이다. 그러나 불행히도 두 가지의 ECC 메모리를 전부 사용 가능한 서버용 보드는 저렴한 가격대에서는 별로 없는 듯. 컴퓨존 사이트에서 Tyan 보드의 사양을 살펴보면 RDIMM/UDIMM을 전부 지원하지만 Supermicro의 보드는 저가격대에서는 ECC unbuffered memory만을 지원한다. ECC 메모리 자체의 가격은 registered의 경우 좀 더 비싸다.

못쓰는 메모리에 구멍을 뚫어서 열쇠고리로 쓰는 사람도 있다지만...

참고 사이트: http://www.servethehome.com/unbuffered-registered-ecc-memory-difference-ecc-udimms-rdimms/ 그리고 국문으로 되어있는 너무나 친절한 자료 사이트는 여기! http://blog.dreamwiz.com/kgstar/3377785

시시하게 끝나버린 LVM 복구

결론만 이야기하자면, 재부팅 한방으로 모든 상황이 종료되고 말았다.

만약 정상적인 재부팅 과정에서 LVM쪽에 문제가 생겨서  root password를 입력하라는 화면이 나왔다면, 커맨드 라인에서 여러가지 명령을 입력해 가면서 망가진 LVM을 되살리기 위해 노력했을 것이다.

하지만 이번의 경우는 좀 달랐다. 프로그램 실행 중에 특정 하드디스크에 오류가 발생했고, 문제가 발생한 논리 볼륨은 자동적으로 read only 상태가 되었다. 정확히는 모르겠지만 LVM과 관련한 모든 메타 데이터는 무사했고, 논리볼륨 자체에 새로 파일을 쓰거나 고치지 않았으니 원본이 그대로 남아있을 가능성이 매우 큰 상태였다.

재부팅을 하기 전에 백업이려도 하려는 의도에서 온갖 방법을 동원하여 다른 디스크에 파일을 옮겼지만, 어차피 문제가 일어난 드라이브는 인식이 되지 않는 상태여서 완벽한 백업은 기대하기 어려웠다. 그나마 네트웍 설정을 잘못 건드려서 복사가 다 끝나가는 마당에 연결이 끊기고 말았다 ㅠㅠ

에휴... 재부팅 말고는 방법이 없겠다 싶어서 일요일 밤, 과감하게 전원을 내렸다가 다시 올렸다. 디스크 체크가 진행된다. 시간이 꽤 많이 걸린다. 디스크 용량이 테라 단위로 올라간 다음에는 디스크 체크 과정을 지켜보고 있기가 어렵다. 너무 시간이 많이 걸리니까. 10% 이상 진행이 된 것을 확인한 뒤 집에 돌아가서 편한 마음으로 '내딸 서영이'나 마저 보기로 하고 차에 올랐다.

그리고 오늘 아침, 많은 비가 내리는 가운데 출근을 하여 서버가 숨겨진(?) 방 문을 열고 키보드를 두드려서 화면을 깨웠다. 오... 반가운 로그인 화면!

이번 사태를 겪으면서 몇가지의 교훈을 얻었다. 정리하자면,

• 24시간 외부 서비스를 하는 컴퓨터는 아니니 가끔 재부팅을 해 주자. 
• HDD는 얼마든지 오류가 발생할 수 있는 장비이다. 주기적인 백업을 반드시 하고, 특히 NAS 도입을 적극 검토하자. 사실 나는 그동안 전문 서버용으로 SCSI HDD가 있다는 것은 알았지만, "기업용" HDD라는 제품이 따로 있는 것을 전혀 몰랐다. 혹자는 일반 데스크탑 PC용이나 기업용 모두 신뢰도는 비슷하다고 하지만... 한마디로 복불복이라는 것이다. [참고자료: Google's Disk Failure Experience, 국문 요약 및 해설은 여기, 2007년도 자료라서 지금은 어떻게 달라졌는지 알 수 없지만...]
• 그동안 체험과 인터넷 검색을 통해 쥐가 종이를 쏠듯이 단편적으로만 알고 있던 리눅스 시스템 관련 지식을 좀 더 체계적으로 확충해야겠다는 생각이 든다. 아니할 말로 내 리눅스 경력이 이제 20년이 넘어가는데(기타 연주 경력은 30년이 넘어가는구나...) 이제 뭔가 좀 보여줄 때가 되지 않았는가?

리눅스 LVM 복구하기

국공립기관에서 클라우드 서비스를 쓰지 못한지는 꽤 되었는데, 드디어 구글 드라이브까지 막히고 말았다. 이러다가 구글 블로거나 심지어 지메일까지도 쓰지 못하게 되지는 않을까? 아직 구글 블로거는 되지만 이미지를 올리려고 하니 그것조차 되질 않는다. 아마도 구글 드라이브와 밀접한 연결이 되어 있어서 그런 모양이다.

뭔가 다른 대책을 강구해야 되겠다.

lvm으로 묶어서 사용하던 HDD에 문제가 발생했다. 6개의 HDD 베이가 있는 랙마운트 서버에서 5개를 묶어서 쓰고 있었는데, 그중 하나에서 I/O 에러가 생기면서 5개만으로 제대로 인식이 된다. 아예 부팅이 되지 않는 상황이라면 정말 난감했을 것이다. 문제가 발생한 디스크에 있던 자료를 되살릴 수 있을지는 잘 모르겠다.그나마 파일들이 드문드문 여러 디스크에 나뉘어 있으니 다행이다.

안전을 위해 일단 파일의 백업을 실시하는 중이다.다른 데스크탑(역시 리눅스)에 새 디스크를 연결하고 scp와 rsync로 파일을 옮기고 있는데, 같은 건물 안의 네트웍에 물려 있으면서 왜 이렇게 전송 속도가 느린지 모르겠다. 초당 10 MB나 될까? 도저히 참을 수가 없어서 1.5TB USB 하드디스크를 물리니 인식이 안된다. 파일 시스템이 HUFS/NTFS인데 단번에 인식하질 못한다. 검색을 해 보니 NTFS-3G라는 패키지를 깔아야 한단다. 약간의 수고를 들여 이를 설치한 다음 디스크를 직접 연결하니 훨씬 높은 전송 속도가 나온다.

남는 시간 동안 새 하드 디스크 하나를 SATA-USB 어댑터에 연결하여 다른 리눅스 머신에 연결한 다음 파티션과 포맷을 시도하려니 이것 역시 쉽지가 않다. fdisk는 이제 parted에 자리를 내어 주고 있다는데, 사용법이 영 생소하다. GParted를 찾아서 설치하고 이용하려는데 포맷에 너무 시간이 많이 걸린다. 이건 아니다 싶어서 컴퓨터 본체를 열고 SATA 포트에 직접 연결한 다음 파티셔닝과 포맷을 진행하였다. 이를 분리하여 USB 어댑터를 경유하여 연결했을 때 잘 인식되는 것을 확인한 뒤(우분투 12.04), 문제가 발생한 서버에 가져가서 꽂아 보았다. 전혀 인식이 안된다. 뭐가 문제인가...

웹을 뒤져보니 parted는 ext3 파일시스템을 제대로 지원하지 못한다고 한다[참고]. 하지만 GParted에서 파일시스템을 만들 때 분명히 ext3가 항목 중의 하나로 있었다. 이게 문제가 아니라면, SATA-USB 어댑터에 문제가 있는가? 그러나 이 장비는 문제가 되었던 리눅스 서버에서 ODD를 내부적으로 연결하기 위해 사용하던 것이다.

작년에 처음 LVM을 이용하기 시작했을 때, 기본 개념을 이해하는 것이 결코 쉽지 않았었다. 새 주가 시작되면 본격적인 하드 교체 작업을 해야 하는데, 사실 문제 없이 잘 진행이 될지 확신을 하지 못하는 상태이다. 설상가상으로 새 디스크를 꽂고 인식시키는데 이렇게 공부할 일이 많다니... 예전에는 IDE 디스크밖에 없었고 fdisk나 disk druid로 대충 필요한 일을 다 했던 것으로 기억하는데 말이다.

현재 볼륨 그룹은 하나 뿐이고, 논리 볼륨도 하나다. 아직 여유 공간이 2.2 TB 정도 남아 있으므로, 문제가 된 디스크(1.8TB)를 제거하는 것은 크게 어렵지 않을 것이다. 물리 볼륨을 추가할 필요는 없을테고(이미 모든 베이가 다 차 있으므로 불가능하다), 볼륨 익스텐트만을 2 TB 정도 줄여 놓은다음 에러가 난 디스크만 제거하면 될 것이다. 물론 내가 잘못 알고 있는 것이 있을 수도 있고, 작업이 이 시나리오대로 진행되지 않을지도 모른다.

너무 싸구려 디스크를 쓴 것인가...