'스크랩북'에 해당되는 글 3건

  1. 이런곳에서 살고싶네 2007.12.14
  2. linux 에서 시간 동기화 2007.02.19
  3. 왜 linux 에서 조각모음이 필요없는가! [수정1차] 2 2007.02.03

이런곳에서 살고싶네

from 스크랩북 2007. 12. 14. 04:34
사용자 삽입 이미지
,

linux 에서 시간 동기화

from 스크랩북/Linux 2007. 2. 19. 15:15


적용범위: ntpupdate 또는 rdate 가 설치되어 있는 모든 운영체제

ntpupdate -u time.nuri.net 또는 rdate -p -s timeservername

-u 스위치는 방화벽으로 시간동기화 포트가 막혀있을 때 사용한다.

아래는  시간서버 목록이다.

**** Time Servername
time.kriss.re.kr
time.bora.net
time.nuri.net
www.hanyang.ac.kr
www.hongik.ac.kr
www.korea.ac.kr
www.skku.ac.kr
www.snu.ac.kr 



----------------------------------------

위의 것은 운영체제에서의 시각만 맞출 뿐 하드웨어 시각에는 적용되지 않는다.
다음 명령을 통해 BIOS의 시각을 맞춰주자.

hwclock --systohc

그냥 hwclock 를 하면 현재 BIOS가 갖고 있는 시각을 출력하고, 올바른 시간과의 차이를 출력한다.

---------------------------------------

One more thing

아래는 coffeenix 의 좋은진호 님께서 체계적으로 정리하신 글.
출처 : http://www.coffeenix.net/board_view.php?cata_code=0&bd_code=19&bpage=&bd_search_type=all&bd_search=%BD%C3%B0%A3%20%B5%BF%B1%E2%C8%AD


전에는 rdate time.nuri.net 또는 ntpdate -b time.kriss.re.kr
로 동기화만 했는데, 좀더 체계적으로(?) 정리할 필요가 있어서 적어봤다.

1. 우리나라의 NTP(Network Time Protocol) 서버

 1) Stratum 1 서버 :
    GPS 위성으로 부터 표준시각정보를 받는 타임 서버를
    NTP Primary Time Server 혹은 Stratum 1(one) 라고 부름

    데이콤 (gps.bora.net), 코넷 (ntp.kornet.net), GNGIDC,
    부산대학교 (ntp1.cs.pusan.ac.kr / ntp2.cs.pusan.ac.kr),
    한국 표준과학 연구원 시간 · 주파수 연구실 (time.kriss.re.kr)

 2) Stratum 2 서버 :
    Stratum 1 서버로 부터 표준시간을 받는 타임서버를
    TP Secondary Time Server 혹은 Stratum 2 서버라고 부름

    PSINet Korea (time.nuri.net),
    GNGIDC (ntp1.gngidc.net / ntp2.gngidc.net),
    이대부속 초등학교 (ntp.ewha.net / ticktock.ewha.net)


2. rdate를 이용한 시간 동기화

 지정한 타임서버로 부터 시간을 확인하거나 동기화 시킨다.

 1) 타임서버의 표준시간을 확인한다.

    rdate time.nuri.net
    rdate: [time.nuri.net]  Tue Mar 18 16:38:47 2003

 2) 시스템 시간을 타임서버 시간에 동기화 시킨다.

    rdate -s time.nuri.net

3. ntpdate를 이용한 시간 동기화

 1) 동기화

     ntpdate -b -s time.kriss.re.kr

    -s : 결과를 화면이 아닌 syslog로 보냄

 2) 다음과 같은 오류가 발생한 경우

 
 [root@truefeel root]# ntpdate -b time.kriss.re.kr
 17 Mar 21:03:25 ntpdate[8244]: no server suitable for synchronization found
 


 ->  NTP 프로토콜은 UDP port 123 을 사용하는데, 이 포트가 방화벽 등으로
      막혀있는 경우에는

      ntpdate -u time.kriss.re.kr

      처럼 -u 를 옵션을 사용해서 다른 포트 사용하도록 한다.

 3) 사용 예

 
 [root@truefeel root]# date
 월  3월 17 21:40:35 KST 2003
 [root@truefeel root]# date 03172150 <- 강제로 시간을 3.17일 21:50 으로 변경함

 월  3월 17 21:50:00 KST 2003
 [root@truefeel root]#
 [root@truefeel root]# ntpdate -u time.nuri.net <- 시간을 동기화 함
 17 Mar 21:40:44 ntpdate[8835]: step time server 203.255.112.96 offset -557.336058 sec
 [root@truefeel root]#
 [root@truefeel root]# date
 월  3월 17 21:40:46 KST 2003  <- 시간이 동기화 됨
 


 위에서 'offset -557.336058 sec'은 타임서버의 시간(reference time)과 로컬 서버와의
 시간 차이를 나타냄

 4) ntpdate의 2가지 시스템 콜

 ntpdate는 settimeofday(), adjtime()의  2가지 시스템 콜로 시간을 설정한다.
 settimeofday()은 timezone과 시간을 설정하고,
 adjtime()은 점근적 시각 보정 방식으로 커널 클럭을 조정한다. 주로 시간 동기화에 사용한다.

 ntpdate는 옵션(-b, -B)을 지정하지 않으면 현재 시스템 시간과 차이가 128ms 이상이면
 settimeofday()을, 이내이면 adjtime()을 사용한다.
 또한 강제적으로 ntpdate -b 로 settimeofday()를, ntpdate -B로 adjtime()를 사용할 수 있다.

 ntpdate 실행 결과 메시지에 'step time server...'로 표시되면 setimeofday()가 사용되었고,
 'adjust time server...' 로 표시되면 adjtime()가 사용되었다.

 
 [root@truefeel root]# ntpdate time.nuri.net
 14 Mar 01:09:31 ntpdate[3127]: step time server 203.255.112.96 offset 82.763348 sec
 [root@truefeel root]# ntpdate time.nuri.net
 14 Mar 01:22:30 ntpdate[3182]: adjust time server 203.255.112.96 offset -0.064531 sec
 


 부팅할 때는 ntpdate -b 로, cron등으로 정기적으로 시간조절을 할 때는 옵션없이 ntpdate
 사용하기를 하기 바란다.

 5) 디버깅 모드

    - 디버깅 모드는 local 서버의 시간을 변경하지는 않는다.

 
[root@truefeel root]# ntpdate -d time.nuri.net
18 Mar 17:33:23 ntpdate[2169]: ntpdate 4.1.1a@1.791 Sat Aug 31 18:27:31 EDT
2002 (1)
transmit(203.255.112.96)
receive(203.255.112.96)
transmit(203.255.112.96)
receive(203.255.112.96)
transmit(203.255.112.96)
receive(203.255.112.96)
transmit(203.255.112.96)
receive(203.255.112.96)
transmit(203.255.112.96)
server 203.255.112.96, port 123
stratum 2, precision -18, leap 00, trust 000
refid [192.6.38.127], delay 0.04927, dispersion 0.00092
transmitted 4, in filter 4
reference time:    c2215828.4ea9e000  Tue, Mar 18 2003 17:32:40.307
originate timestamp: c2215853.6ad1b000  Tue, Mar 18 2003 17:33:23.417
transmit timestamp:  c2215853.a19695d9  Tue, Mar 18 2003 17:33:23.631
filter delay:  0.05023  0.05008  0.04927  0.06329
        0.00000  0.00000  0.00000  0.00000
filter offset: -0.22637 -0.22621 -0.22640 -0.23302
        0.000000 0.000000 0.000000 0.000000
delay 0.04927, dispersion 0.00092
offset -0.226409

18 Mar 17:33:23 ntpdate[2169]: adjust time server 203.255.112.96 offset
-0.226409 sec
 


4. 주의 사항

 1) time.kriss.re.kr 서버는 1초내에 여러번 접속을 시도할 경우 해당 IP를 차단 시키므로
    테스트를 하더라도, 시간 간격을 두고 하도록


-------------------------------


제가 쓴 글 내용의 지적/퍼온 글에 대한 문제제기는 답글로 해주세요.
만일 문제가 된다면 자삭 예정입니다.
마지막으로 체계적으로 정리하여 공개해 주신 좋은진호님께 감사드립니다 ~_~
,

왜 linux 에서 조각모음이 필요없는가! [수정1차]

from 스크랩북/Linux 2007. 2. 3. 02:43

이 글은 http://blog.empas.com/mycoffee/15302774 에서 스크랩한 글임을 미리 밝힙니다..

간단하게 내용을 요약하자면, 리눅스의 파일 시스템은 파일을 배치함에 있어 충분한 여유공간을 배려하므로 단편화가 발생하긴 하지만 심각한 수준은 아니며, 단편화가 발생한다고 해도 시스템 퍼포먼스를 떨어뜨리거나 운영이 어려울 정도의 장애를 느낄 정도의 문제가 발생하지 않기 때문에 리눅스의 파일시스템에서는 조각모음이 필요가 없다는 결론인듯 합니다. ^-^

유닉스 파일시스템의 단편화에 대한 또다른 번역을 소개해 드린다면
http://wavetheblue.tistory.com/79 를 참조하시면 좋을 것 같은데요..

유닉스에서의 단편화가 왜 최소화 되며 시스템 퍼포먼스에 영향을 미치지 않는가? 에 대한 상기 링크의 답변은 아래와 같은듯 보입니다.

1. UFS 는 연관된 데이터블록을 같은 실린더 그룹에 기록하게 한다.
   - 파일 접근시간/탐색시간을 최소화 한다

2. ext2/ext3 는 특정 파일의 블록을 최대한 근거리에 위치시키고 파일 크기증가에 대비해 근접블록을 미리 예약한다
    - 파일이 실제 사용되기 전에 미리 디스크 데이터 블록에 배치
    - 예약블록이 오랜기간 존재하여 그 용량이 꾸준히 증가하는 파일이 있다면 단편화가 크게 발생할 수 있다


좀 더 내용을 심층적으로 이해하고 싶은데 역시 공부를 안해서 그런지, 어렵네요 ~_~

 저번 학기 운영체제 수업시간에, inode 기반의 파일시스템에 대해서 배운적이 있는데, inode는 데이터가 저장된 위치를 가리키는 포인터이고, 파일 할당 테이블에 특정 파일이 등록되면, 그것은 실제 데이터가 저장된 하드디스크의 블록을 가리키는 inode를 참조하게 됩니다. 그러나 하나의 파일에서 참조하는 inode의 갯수는 제한되어 있기 때문에 inode는 또다른 inode 를 참조할 수 있는 등의 기법이 사용된다고 배운 것 같습니다만.

그럼 그 inode 기반의 파일시스템 중 하나가 ext2,3 시리즈인것으로 알고 있는데, 아래의 설명과 매치가 잘 되지 않는군요.. 아래는 단순히 파일할당 테이블로 보입니다만...

수양이 엄청나게 부족했다는 것을 뼈저리게 느끼게 되는군요..

일단 오늘 하루를 마치고, 내일 더 책을 찾아보고 생각을 해 봐야 겠습니다.

결론은 이해가 가지만, 실제 동작하는 모습이 그려지질 않아 완벽하게 이해가 가질 않는군요! ;ㅅ;



오늘의 최종 결론 : 열심히 공부할때 공부 제대로 해놓읍시다.. ;ㅅ; (어흑)

추가로 BSD 기반의 Mac OS X 에서는 어떨까? 하시는 분들은 아래 링크를 참조해 보시는것도 좋겠습니다.
http://luv4.us/5

실제로 Mac OS X 을 사용하다 보면 아래와 같은 상황이 하나 있었습니다.

만일 특정 디렉토리에 기가나 메가급 (한 200메가 이상? ) 파일들이 10개 이상 있는 상황에서 그것들을 다른 디렉토리나, 파티션으로 옮기는 작업을 한적이 있었습니다.

그 중 3개를 /Volumes/DATA 로 옮기도록 드래그&드랍을 걸어두고 다시 7개 정도 파일을 홈 디렉토리 ~ 로 복사하기위해 드래그&드랍을 하면, "파일이 사용중이기 때문에 복사/이동 할 수 없다" 라는 메세지가 뜹니다.

아마 운영체제 자체에서 단편화 제거를 위해 블록을 걸어둔게 아닐까, 라고 생각하고 있습니다.


여하튼!! 각설하고 슬슬 소개해 드리도록 하겠습니다.

아래는 퍼온 글입니다. 열심히 번역하신 블로그 주인장님게 댓글이라도 한번 남겨드리는게 어떨까요? ^-^


--------------------------------------------------------


※ 이 글은 [Why doesn't Linux need defragmenting?] 의 내용을 번역한 것이다. 혹시 오류가 있으면 지적 부탁드린다.
 
 
 
 
 
지겹게도 되풀이되어 나오는 질문 하나가 있죠: "왜 리눅스의 파일 시스템은 조각 모음이 필요 없나요?". 이 글을 통해 질문에 대한 해답을 한 방에 정리해 보고자 합니다.
 
단순히 수많은 기술적 설명들을 어설프게 더듬거리기보다, ASCII 그림을 사용하는 게 훨씬 효과적일 것 같습니다. 그런 고로, 전반적인 설명을 진행하는 데 이 그림을 사용하도록 하겠습니다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
b  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
e  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
g  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
h  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
i  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
j  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
k  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
l  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
m  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
n  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
o  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
p  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
q  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
r  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
v  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
w  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
x  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
y  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
z  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
이것은 완전히 비어 있는 - 그래서 전부 0 으로 돼 있죠 - (매우 작은) 하드 드라이브를 나타내는 것입니다. 상단부와 좌측의 a-z 로 된 격자는 데이터의 개개의 바이트의 위치를 나타냅니다: 면 좌측 상단은 aa, 우측 상단은 za, 그리고 왼쪽 하단은 az 같은 식으로 말이죠. 무슨 뜻인지 이해가 가실 겁니다.
 
우선 대부분의 유저들에게 친숙한 간단한 파일 시스템 종류, 그러니까 조각 모음을 간간이 해 주어야 할 만한 걸로 시작해 보죠. USB 플래시 드라이브의 경우 Windows 유저들과 Linux 유저들 모두가 FAT 파일 시스템을 사용하는데, 비록 이것이 파일 시스템으로써 중요하긴 하지만, 단편화가 심각한 수준으로 발생한다는 문제가 있습니다.
 
(FAT) 파일 시스템에 파일을 하나 더하면, 하드 드라이브는 다음과 같이 보일 겁니다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t a e l e 0 0 0 0 0 0 0 0 0 0
b  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  H e l l o , _ w o r l d 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
(g 부터 z 까지의 빈 열들은 생략)
 
지금 보고 계신 이 그림을 설명하자면, 디스크의 첫 네 줄은 TOC(Table of contents) 로써 할당된 상태입니다. 이 TOC 는 파일 시스템 상에 존재하는 모든 파일의 위치를 저장합니다. 위의 예에선, TOC 는 "hello.txt" 라는 이름의 하나의 파일을 포함하고 있으며, 이 파일의 내용은 ae 부터 le 사이에 위치한다는 것을 알려 주고 있습니다. 해당되는 위치를 보면 파일의 내용 - "Hello, world" - 이 적혀 있는 걸 확인할 수 있습니다.
 
아직은 문제 없죠? 그럼 이제 파일을 하나 추가해 보겠습니다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t a e l e b y e . t x t m e z
b  e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  H e l l o , _ w o r l d G o o d b y e , _ w o r l d
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
보시는 것처럼, 두 번째 파일은 첫번째 파일 바로 뒷부분에 추가되었습니다. 여기서의 기본적인 아이디어는 모든 파일이 한데 모여 있으면 그만큼 접근도 빨라지고 쉬워진다는 것입니다. 하드 드라이브에서 가장 느린 부분은 스타일러스 (역주: Head actuator 를 말하는 듯 합니다) 로, 이것이 적게 움직일 수록 읽기/쓰기 시간은 그만큼 빨라집니다.
 
하지만 이러한 방식에는 문제가 따르는데, 첫 번째 파일을 수정해 보면 이를 확인할 수 있습니다. 우리의 "Hello" 가 보다 열광적으로 보이도록 느낌표를 몇 개 추가해 볼까요? 하지만 문제가 있습니다: "bye.txt" 파일이 연이어 기록되어 있기 때문에, 현재 파일 시스템 상에 이러한 느낌표를 추가할 만한 공간이 없는 것입니다. 선택의 여지는 단 두 가지밖에 없습니다만, 어느 것도 이상적이진 않습니다:
 
  1. 원래 위치에 있던 파일을 지우고, 더 커진 새로운 파일을 두 번째 파일의 뒷부분에 붙입니다.
  2. 파일을 단편화합니다. 그러면 두 부분으로 나뉘어 존재하게 되지만 여전히 빈 공간은 없습니다.
 
그림으로 나타내자면, 첫번째 방법의 경우는 다음과 같습니다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t a f n f b y e . t x t m e z
b  e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  0 0 0 0 0 0 0 0 0 0 0 0 G o o d b y e , _ w o r l d
f  H e l l o , _ w o r l d ! ! 0 0 0 0 0 0 0 0 0 0 0 0
 
두번째 방법은 다음과 같습니다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t a e l e a f b f b y e . t x
b  t m e z e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  H e l l o , _ w o r l d G o o d b y e , _ w o r l d
f  ! ! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
이것이 FAT 파일 시스템에 정기적으로 단편화 제거 작업이 필요한 이유입니다. 모든 파일들은 서로간에 딱 붙어서 위치하게 되기 때문에, 파일이 커질 경우 해당 파일은 조각나 버리고, 파일이 작아질 경우 (파일 사이에) 빈 틈이 남게 됩니다. 머지 않아 하드 드라이브는 파일 조각들과 빈 틈으로 가득하게 되고, 성능도 떨어지기 시작합니다.
 
이제 이와는 다른 철학을 가지고 있는 Linux 를 한 번 보죠. Windows 파일 시스템은 사용자가 단일 유저일 경우 이상적인 시스템으로, 다소 오래 된 방식인 각각의 파일을 한 번에 하나씩 접근하는 방법을 사용합니다. 하지만 Linux 는 항상 다중 유저 기반의 시스템으로써 설계되었습니다: 동시에 두 명 이상의 유저들이 하나의 파일에 동시에 접근하는 것을 보장하도록 되어 있지요. 그래서 Windows 의 파일 시스템과는 다른 방향에서의 접근이 이루어졌습니다. Linux 파일 시스템 상에 "hello.txt" 파일을 만들었을 경우, 다음과 같이 됩니다.
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t h n s n 0 0 0 0 0 0 0 0 0 0
b  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
g  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
h  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
i  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
j  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
k  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
l  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
m  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
n  0 0 0 0 0 0 0 H e l l o , _ w o r l d 0 0 0 0 0 0 0
o  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
p  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
q  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
r  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
v  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
w  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
x  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
y  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
z  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
그리고 여기에 다른 파일이 추가될 경우:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t h n s n b y e . t x t d u q
b  u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
g  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
h  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
i  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
j  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
k  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
l  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
m  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
n  0 0 0 0 0 0 0 H e l l o , _ w o r l d 0 0 0 0 0 0 0
o  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
p  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
q  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
r  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u  0 0 0 G o o d b y e , _ w o r l d 0 0 0 0 0 0 0 0 0
v  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
w  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
x  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
y  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
z  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
이러한 접근법의 현명한 점은 디스크의 스타일러스가 중앙 부분에 자리할 수 있다는 것, 그리고 일반적으로 대부분의 파일들이 비교적 근접해 있을 수 있게 된다는 점입니다: 일반적인 Linux 파일 시스템들은 결과적으로 다들 이렇게 돌아가죠.
 
그럼 이 파일 시스템에 느낌표를 추가할 경우, 어떤 문제점이 발생하는지 한 번 살펴 봅시다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t h n u n b y e . t x t d u q
b  u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
e  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
g  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
h  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
i  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
j  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
k  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
l  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
m  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
n  0 0 0 0 0 0 0 H e l l o , _ w o r l d ! ! 0 0 0 0 0
o  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
p  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
q  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
r  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u  0 0 0 G o o d b y e , _ w o r l d 0 0 0 0 0 0 0 0 0
v  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
w  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
x  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
y  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
z  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
네, 그렇습니다: 문제가 전혀 없죠.
 
Windows 는 모든 파일들을 하드 드라이브의 시작 부분에 최대한 가까이 위치시키려고 하기 때문에, 파일들의 크기가 커지고 여유 공간이 없을 경우 지속적으로 파일이 단편화되어 버립니다.
 
(이에 반해) Linux 는 파일을 디스크 전반에 흩어놓기 때문에 파일의 크기가 변하더라도 이를 수용할 수 있는 여유 공간이 충분합니다. 또한 파일의 재배열 작업도 신속하게 이루어지는데, 이는 파일을 이리저리 옮길 수 있는 빈 공간이 많기 때문에 가능합니다. Windows 파일 시스템의 단편화 제거 작업은 보다 무거운 작업이고 때문에 평소 컴퓨터 이용 중에 이러한 작업을 하기엔 실용성이 떨어집니다.
 
따라서 Linux 에 있어서 단편화는 디스크가 완전히 꽉 차서 큰 파일이 쪼개지지 않고선 들어가지 못 할 만큼 빈 틈이 없을 경우에만 발생합니다. 디스크가 80% 이상 차 있지 않은 이상, 이런 일은 발생할 가능성이 없습니다.
 
참고로 한 가지 알아 두셔야 할 것이 있는데, OS 측에서 드라이브의 단편화 제거 작업이 완료되었다고 하더라도 하드 드라이브의 근본 구조 상 여전히 단편화가 존재할 수 있다는 점입니다: 일반적인 하드 드라이브는 흔히 플래터라고 알려진 여러 개의 디스크가 들어 있습니다.
 
예를 들어 하드 드라이브가 실제로 두 개의 플래터로 이루어져 있다고 가정하고, 첫번째를 aa 부터 zm 까지, 두 번째를 an 부터 zz 까지로 구분해 봅시다:
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
b  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
e  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
g  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
h  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
i  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
j  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
k  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
l  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
m  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

   a b c d e f g h i j k l m n o p q r s t u v w x y z

n  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
o  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
p  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
q  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
r  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
v  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
w  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
x  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
y  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
z  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
다음의 파일은 m 열로부터 n 열까지 주욱 이어져 있기 때문에 (OS 레벨에선) 단편화가 되어 있지 않다고 여겨지지만, 이것은 이 파일을 읽기 위해선 스타일러스가 플래터의 맨 끝에서부터 맨 처음으로까지 이동해야 한다는 사실을 무시한 것입니다.
 
   a b c d e f g h i j k l m n o p q r s t u v w x y z

a  T O C h e l l o . t x t r m e n 0 0 0 0 0 0 0 0 0 0
b  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
c  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
e  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
g  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
h  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
i  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
j  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
k  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
l  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
m  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 H e l l o , _ w o

   a b c d e f g h i j k l m n o p q r s t u v w x y z

n  r l d ! ! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
o  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
p  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
q  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
r  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
v  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
w  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
x  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
y  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
z  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
이 글이 왜 Linux 를 설치해도 조각 모음 프로그램이 깔려 있지 않은지를 이해하는 데 도움이 되었으면 합니다. 만약 아니라면, 언제든 의견 주세요.



,
<< previous 1 next >>

티스토리툴바