공룡호가 사는 세상 이야기

OS를 백업하는 방법은 여러가지가 있다. 그 중에서 일반적으로 많이 쓰는 방법은,
동일 스펙의 Internal Disk 2개를 이용하여 미러를 구성하는 방법,
특정 슬라이스에 Cron을 이용하여 주기적으로 Dump를 뜨는 방법이 있다.
Dump를 떠서 새로운 디스크에 넣고, 부트 블록을 심어줌으로 동일한 디스크를 만드는 법은 다음과 같다.

[가정]
현재 OS가 설치된 곳 : c0t0d0s2
새 디스크 : c0t1d0s2

[수순]
1. prtvtoc을 이용, 원본 디스크와 동일한 파티션 구성을 대상 디스크 복제한다.
#prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2

2. 대상 디스크(새 디스크)의 파일 시스템을 새로 구성한다
#newfs /dev/dsk/c0t1d0s2

3. 대상 디스크를 사용하기 위해서는 마운트를 해야 한다.
#mount /dev/dsk/c0t1d0s2 /mnt

4. 원본 디스크에서 Dump를 떠서 대상 디스크에 Restore한다. (시간이 좀 걸린다)
#ufsdump 0f - /dev/dsk/c0t0d0s2 | (cd /mnt; ufsrestore rf -)

5. 마운트 해제
#umount /mnt

6. 대상 디스크에는 부트 블록이 없으므로 부팅이 불가능하다. 부트 블록을 심는다
#installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk/dev/rdsk/c0t1d0s2


Solaris에서 Disk Suite를 이용하여 미러를 구성하는 방법은 다음에~

사용자 삽입 이미지
앞서 리뷰했던 메모리 관련 Article과 관련 있는 기사를 한번 더 보고자 한다.
프로그래밍에서 메모리 결함은 대부분 잘못된 코딩 습관에서 온다고 언급했었다.
사실, 메모리 결함 뿐 만이 아니다. 모든 오류나 결함은 마찬가지이다.
같은 맥락에서, 이번 Article을 읽다가 인상 깊은 구절을 발견했다.
C 프로그램에서 컴파일 옵션에 -O -Wall -W -Wshadow -pedantic을 사용하면, 소스코드에서 올바르지 않거나 의심스러운 부분진단 메시지로 날려준다.

많은 개발팀이 컴파일러가 제공하는 진단 결함을 불치병이나 세금처럼 필요악으로 취급한다.

내 경험으로는 아무리 잘 관리해도 진단 메시지를 무시하는 50만 줄짜리 프로젝트는 오류가 적어도 5000개 정도 존재한다. 물론, 그 중 적어도 몇 개 정도는 자주 발생하는 오류로 드러난다. 결코 음수가 되지 않는 unsigned 정수를 조건으로 사용하거나, 선언한 변수에 철자 오류가 있어 전혀 사용되지 않는 경우 등이다. 모든 컴파일러 진단 메시지를 하나씩 없애가는 과정에서 코드 품질은 극적으로 향상된다. 컴파일러 진단 메시지는 자동화하기가 쉬우므로 비용도 적게 든다

사실, 그렇지 않은가 Error는 수정하지 않으면, 컴파일을 할 수 없으므로 어쩔 수 없이 하게 되지만, Warnning은 그냥 지나치기 일쑤다. 지나치다 보면 이제 손대기 귀찮고 짜증날 정도로 많아지게 되고, 나중엔 아예 손을 쓰기조차 어려워진다. 그래도 컴파일은 된다. 기대하는 대로 작동한다. 하지만 오류는 언제나 잠재 해 있다는 것이 문제이다.

메모리 오류에 한정되어 있지만, 이는 굉장히 중요한 문제이다.
컴파일 옵션을 주어 모든 진단 메시지를 확인하고 그에 따른 진단 과정을 살펴보면서, 올바른 코딩 습관에 대해 다시 한번 더 생각 할 기회와 메모리 오류에 대해 진단하고 해결하는 과정도 함께 익힐 수 있을 것 같다. 코드 품질을 극적으로 높이는 관건은 기술적 혁신이 아니라 문화적인 혁신이다. 맞는 말이다.



메모리 오류
때문에 고생한 적이 한 두번이 아니다. Syntax 오류가 아니라서 더더욱 잡아내기 힘들고, 특수한 상황 설정을 해 놓고 체크하지 않는 한 발견해 내기도 힘들다. 또, 시스템에 따라 발생하는 시기 또한 달라질 수 있어 여간 짜증나는 오류가 아닐 수 없다. 릴리즈 단계까지 발견되지 않는 경우도 있고, 심지어 모 회사 입사시험에도 나왔었다. 메모리 누수가 일어나는 것을 효과적으로 잡아 낼 방법은? 하고 말이다.

메모리 오류의 유형은 1.메모리 누수, 2.할당 오류, 3.dangling 포인터, 4.배열 경계 위반 등이 있는데, 이는 객체지향 언어에서도 크게 다르지 않다.
Article에서는 오류 각각의 케이스 별 예제코드와 그 대처법에 대해서 다루고 있다. 여기서 설명하고 있는 것들로 메모리 오류를 모두 방지할 수는 없다. 하지만, 메모리 오류의 각 케이스를 알고, 그에 대한 일반적인 대처방안, 메모리 도구 등 메모리 프로그래밍의 전략을 익히는 데는 꽤 괜찮은 기사가 아닐까 싶다.

기사 내용에도 언급이 되어 있지만, 대부분의 프로그램 오류는 잘못된 코딩 습관에서 비롯된다(그것은 협업에서도 마찬가지이다). 리뷰라고 할 것 까지도 없지만, 나는 주로 학생 개발자들의 수준에 맞추어 Article을 선택한다. 습관이라는 것은 그게 무엇이든 한 번 굳어지면 고치기 힘들다. 현업에서 개발을 꿈꾸는 많은 학생 개발자들이 올바른 코딩 습관을 기르는 데 조금이나마 도움이 되었으면 좋겠다.

메모리 디버깅 기법(바로가기)

엔디안 방식에 구애 받지 않는 C코드 작성하기
http://www.ibm.com/developerworks/kr/library/au-endianc/


big-endianlittle-endian은 메모리에 저장된 바이트들의 순서를 말하는데, 빅엔디안은 큰 쪽(바이트 열에서 가장 큰 값)이 먼저 저장되는 순서이며, 리틀 엔디안은 작은 쪽(바이트 열에서 가장 작은 값)이 먼저 저장되는 순서이다. 예를 들면 빅 엔디안 시스템에서는 16진수 "4F52"를 저장공간에 "4F52"라고 저장할 것이다.(만약 4F가 1000번지에 저장되었다면 52는 1001번지에 저장) 반대로, 리틀 엔디안 시스템에서는 거꾸로 "524F"로 저장된다.

리틀 엔디안을 사용하는 대표적인 CPU는 Intel 계열 CPU이며, 빅 엔디안을 사용하는 가장 대표적인 CPU는 Sparc 계열 CPU이다. 즉, 사용하려는 시스템 CPU의 엔디안 방식에 따른 호환성의 문제가 발생할 수 있게 되는데, 아키텍처, 프로세서, 네트워크 스택, 통신 프로토콜은 모두 특정한 시점에서 엔디안 방식을 정의해야 하는데, 엔디안 방식이 코드에 영향을 미치는 경우, 런타임시 엔디안 방식을 판별하는 방법, 코드에서 바이트 순서를 뒤집어 엔디안 방식에 구애 받지 않는 방법을 알아보자.

예제 : 엔디안 방식을 모르고 프로그램을 작성할 때 발생하는 위험

#include <stdio.h>
#include <string.h>

int main (int argc, char* argv[]) {
    FILE* fp;

    /* 예제 자료 구조 */
    struct {
        char one[4];
        int  two;
        char three[4];
    } data;

    /* 예제 자료 구조를 채운다. */
    strcpy (data.one, "foo");
    data.two = 0x01234567;
    strcpy (data.three, "bar");

    /* 자료 구조를 파일에 쓴다. */
    fp = fopen ("output", "wb");
    if (fp) {
        fwrite (&data, sizeof (data), 1, fp);
        fclose (fp);
    }
}

위 코드는 모든 시스템에서 문제 없이 컴파일이 되나, 엔디안 방식에 따라 결과는 크게 다르다.(hexdump)

빅 엔디안 (hexdump -C)

00000000  66 6f 6f 00 12 34 56 78  62 61 72 00              |foo..4Vxbar.|
0000000c

리틀 엔디안 (hexdump -C)

00000000  66 6f 6f 00 78 56 34 12  62 61 72 00              |foo.xV4.bar.|
0000000c

이처럼, 엔디안 방식을 고려하지 않은 코드는 예상치 못한 곳에서 복병을 만날 수 있다.
엔디안 방식이 코드에 영향을 미치는 경우, 런타임 시 엔디안 방식 판별, 네트웍 바이트 순서, 바이트 순서 뒤집기 등으로 구성된 재미있는 기사였다.

요즘 SPARC장비들과 매일 씨름을 하고 있다 보니, 관심이 가지 않을 수 없었다. 미션 크리티컬한 업무가 운영중인 시스템들을 다루다 보니 요즘은 특히나 더 조심스러워 진다. 프로그래머도 마찬가지가 아닐까? 플랫폼이 어떤 엔디안 방식을 사용하든 실패하지 않는 코드를 구현하는 것 또한 프로그래머의 몫이리라.

비즈니스의 문제에 있어서는 좋은 의미로 정리된 웹2.0이 내세우는 세가지 키워드가,
자칫 미래지식 경제가 부가 편중된 팔레트의 이론으로 회귀하는데 큰 역할을 하지 않을까.

IT-투데이에서 읽은 박세영 교수님의 글 중에 삽입된 말이다.

진화하는 웹2.0은 다시 또 고상한 단어와 철학으로 포장되고 있다.
"참여, 공유, 개방"
참여
| 표현되어진 의사들이 대중 다수의 것인가 하는 문제와
그 자유로운 표현에 의해 또 다른 사람의 자유와의 대립은 어떻게 할 것인가.
참여의 수준이 특정 분야에서는 매우 저급한 것임을 자각해야 한다.
공유 | 아무런 대가 없이 타인의 재산을 공유라는 미명아래 침해하고 있는 것은 아닌지.
개방 | 숫자로 표현되기 힘든 가치가 어떤 일방적인 잣대로 평가되는 것은 아닌지.

한번 쯤 생각 해 볼 일이다.
과연 이것들이 우리를 조금 더 행복하게 해 줄 것인지.



밀린 일을 하시는 분들도,
평소에 하고 싶었던 취미 생활을 하시는 분들도,
애인과 데이트를 하시는 분들도,
잠을 자며 푹 쉬시는 분들도 계시겠지요~

저는 간만에 찾아온 휴일, 그냥 푹 쉬며 책도 읽고 집에서 뒹굴거리며 보냈습니다만,
뭔가 다른 특별하고 의미 있는 일이 무엇이 있을까 하는 생각을 늘 합니다.

이 글을 보시는 여러분들은, 휴일에는 뭘 하며 의미있는 하루를 만드시는지요?
많은 댓글, 트랙백 부탁드려봅니다~

'일상다반사' 카테고리의 다른 글

영화 '놈놈놈' 감상평  (0) 2008.08.03
don't let me be misunderstood - Santa Esmeralada  (0) 2008.07.21
어수선 했던 주말  (0) 2008.04.07
초대장 드립니다.(마감)  (62) 2008.04.04
커피 한잔 하실라우?  (0) 2008.03.16

부모님 올라오시고, 동생도 함께.
조용조용 지나갔던 일상적인 주말과는 조금 다른 어수선한 주말이었다.
잠을 청했다 일어난 월요일 아침.
고요한 방 안 공기가 조금 어색해 TV리모콘을 몇 번 눌러도 보고,
창문을 열어보니, 어제 내리던 비는 이미 그쳤는데.
왠지 모르게 쓸쓸한 아침.
오늘 같은 날에는 사무실 로비에 있는 별다방에서 커피나 한잔.
출근이나 합시다.

초대장이 쌓이는 걸 깜빡하고 살았습니다.
오늘 간만에 기분 좋은 모임에 다녀오는 길에, 제 블로깅에 대해 많이 반성했습니다.
앞으론 좀 더 활발한 블로거가 되고자 하는 의미에서, 초대장 한번 드려볼까요?
이미 가입된 메일주소, 탈퇴한 지 얼마 되지 않은 메일주소 등은 발송이 되지 않으니 참고하세요.
40장입니다. 댓글 달아주시면 보내드립니다.

- 마감되었습니다. 다시 초대장이 생기거든 또 초대 해 드리겠습니다.
초대 과정에서 이미 초대장을 다른 분에게 받으신 분, 이미 가입되신 분이 계셔서 부득이 초대장을 드리지 못하는 경우가 발생하였습니다. 양해 바랍니다 ^^

- 전통적인 RSS
RSS는 RDF site Summary, Rich Site Summary 등의 약칭으로 뉴스나 블로그와 같이 컨텐츠 업데이트가 잦은 웹사이트에서 업데이트된 정보를 사용자들에게 쉽게 제공하기 위해 XML을 기초로 만들어진 데이터 포멧이다.
기존 웹 사이트들이 서비스했던 일방적인 메일링 서비스는 해당 사이트 관리자가 일방적으로 내용을 요약하여 발송하는 수동적인 형태였다면, RSS는 하나의 웹 사이트 내에서도 원하는 카테고리의 내용만을 수집할 수 있다는 점에서보다 진보적이고 능동적인 형태를 취한다.

- 새로운 한계 RSS
이것이 많은 사람들이 RSS를 사이트 피드 같은 배급의 목적에 사용한다고 알고 있는 내용이나, 몇 년 전부터 데이터 배포나 연락처 관리와 같은 목적으로 여타 애플리케이션의 저장 포멧으로도 쓰여왔다.
즉, 데이터를 RSS 형태로 저장함으로써 RSS 수집/구독 프로그램을 데이터에 접근하는 데에도 사용할 수 있다는 의미가 되는데, 예전의 관계형 데이터에서 저장되었던 방식으로 RSS를 사용하여 정보를 저장할 수 있게 된다.

- 튜토리얼에 대해
RSS 포멧과 몇 가지 실제 피드 샘플을 소개하는 것을 시작으로 기존 포멧을 바꿔 이를 다른 목적을 위해 재정의 한다. 테이블 세 개로 데이터베이스 포멧을 정의하고 이 테이블들을 쿼리하여 전통적인 SQL SELECT 모두를 흉내낼 수 있음을 보여주고 결합적 룩업을 제공한다. 마지막으로 쿼리의 결과를 처리하거나 XML폼으로 남겨두거나 이를 XSLT를 사용하여 사용자에게 보여줄 수 있는 다양한 방법으로의 변환법에 대해서도 다루고 있다.

- 코멘트
RSS를 데이터 수집을 보다 효과적으로 하기 위한 용도로 사용되는 것이나, 대부분 웹사이트, 블로그, 뉴스 등의 기사들을 수집하는데 이용되었던 것이 사실이다. 하지만 기본 포멧만 갖춘다면 기존의 수집기를 사용하면서도 또 다른 의미를 가지는 데이터들을 효과적으로 수집/관리할 수 있게 해 줄수 있다는 점에서 재미있는 시도이다. 그리고 실제로 충분히 흥미롭다. 그룹 내에서 서로의 연락처와 그에 관련된 각종 정보들을 공유하는 방법, 일정 관리에 적용하는 방법 등 시도해 볼 만한 곳이 많을 것이다. 아래 원문의 튜토리얼과 그에 따른 참고사항을 링크한다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/x-rssdatabase/index.html
참고 : http://www.ibm.com/developerworks/kr/library/tutorial/x-rssdatabase/resources.html

이 튜토리얼을 어렵지 않게 수행해 낸 사람이라면, "사용자 정의 가능한 RSS 피드 수집기 구현하기" 기사에도 관심을 가져보기 바란다. ( http://www.ibm.com/developerworks/kr/library/wa-aj-rssphp/ )

Ajax의 출현은 기존의 웹 애플리케이션 개발 방식을 완전히 뒤엎었다.
기존의 정적인 HTML 문서에서 사실상 불가능했던 획기적인 기능을 구현해 줄 수 있도록 해 주며, 특별한 프로그램을 로컬 환경에 설치하지 않고서도 로컬 환경에서 작동하는 각종 APP들의 기능을 웹 상에서 바로 구현할 수 있다는 점이 Ajax에 주목하는 많은 이유들 중 하나이다.

그런데, 이러한 Ajax의 출현으로 많은 이들이 Ajax를 도입/적용하면서 문제점들이 생겨날 수 있다는 점에 주목하자. 어쩌면 사소한 문제라고 생각할지는 모르나 사실은 그렇지 않다.
Ajax가 사이트를 구할 수 있느냐, 망치느냐는 Ajax를 사용해야 할 부분과 시점을 얼마나 정확하게 판단하느냐에 따라 달라진다.

본문 내용 중 일부를 요약하자면 다음과 같다.
Ajax를 이용, 페이지의 일부분을 자동으로 업데이트하는 것은 확실히 매력적이고 참신하다. 하지만 이런 페이지들이 웹 서버에는 악몽이 될 수도 있다. 하루에 1000명이 방문하는 소규모 웹 사이트라면 큰 문제가 되지 않겠지만, 사이트를 구성하는 각각의 웹 페이지가 Ajax를 사용해서 1초마다 리프레시되고, 한 명이 평균적으로 10분간 페이지에 머무른다고 가정하면, 사이트는 갑자기 하루에 60만 페이지 요청을 처리해야 하는 부담을 안게된다. 단순히 Ajax를 적용한 것 뿐인데 말이다.
즉, 실시간일 필요가 없는 웹인가를 판단해야 한다는 의미가 된다.

또한, 사이트가 Ajax를 사용해 너무 잦은 업데이트를 하게 되면, Back과 Forward버튼 그리고 북마크가 깨진다는 것. 사용자는 Back버튼을 클릭하여 이전 페이지나 뷰로 넘어가기를 원하지만 실제로는 초기 뷰를 표시하는 등과 같이 사용자 경험을 무시하게 되는 결과를 낳을 수도 있다는 점이다.

이 외에도 Ajax를 이용하여 더 나은 웹을 만들고자 하는 노력은 곳곳에서 이루어지고 있으나, 무차별적인 적용은 오히려 해가 된다는 것을 경고하고 있다. 그것을 사용해야 할 부분과 시점을 명확히 판단하는 것.

자주 발생할 수 있는 문제들을 피하고 경험을 증진할 수 있도록 하기 위해 IBM developerWorks의 다음 Article을 참고하자.

링크 : http://www.ibm.com/developerworks/kr/library/wa-aj-when/