'분류 전체보기'에 해당되는 글 22건

  1. 왜 linux 에서 조각모음이 필요없는가! [수정1차] 2 2007.02.03
  2. 세상에는 똑똑한 사람이 넘친다 2 2007.01.25

왜 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 를 설치해도 조각 모음 프로그램이 깔려 있지 않은지를 이해하는 데 도움이 되었으면 합니다. 만약 아니라면, 언제든 의견 주세요.



,

세상에는 똑똑한 사람이 넘친다

from My Life 2007. 1. 25. 13:50

>>> 지금부터 소개해 드릴 글은 "다음/세계엔"에 뜬 어떤 분의 글을 퍼온 것입니다 <<<





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


다음 메인에 뜬 “일본서 연봉 1000만엔 이상 받기” 라는 글을 보고 혹시나 잘못된 정보로 현혹되시는 분이 있으실 수 있다는 염려가 들었기에 키보드를 두들겨 봅니다.

 

일본에는 많은 한국인 유학생이 있습니다. 정말 다양한 목적을 가지고 여러 분야에서 열심을 다하고 계시는 분들이 많이 계시지요. 다양한 상황을 전부 경험해 본 것은 아니지만 그 글을 읽고 저는 제 경험 속의 학부1학년생 혹은 유학 온지 얼마 안된 많은 분들과 너무나 생각이 닮았다는 느낌을 지우기 어려웠습니다. (서울대를 가는 방법을 몰랐다는 것이나... (가도 중간은 했다??), 전혀 다른 상황의 사람들(미국 학생들)이 주로 본다는 싸이트를 소개하지 않나, 실제로 현재 투자은행에 근무하는 사람의 이야기로는 믿기 힘든 수준의 카더라통신, 리쿠르트 싸이트의 소개, 한국어 잘 구사하는 재일교포가 많아서 한국어는 메리트가 없다 라는 등. 무슨 초등학생 글도 아니고) 그 정도의 현실 인식을 가진 분과는 더 이상 긴 이야기를 해도 서로가 별로 득이 될 것 같지 않습니다.

 

조목조목 이해하기 힘든 주장들을 반박 할 수도 있지만, 그저 제 생각을 써볼까 합니다.

 

그 글을 읽고 가장 먼저 떠오른 말이 있었습니다. 

 

“오늘날 인터넷에 연결이 가능한 아이라면, 만약 그 아이가 충분한 호기심과 인터넷 접속 수단만 갖고 있다면, 그건 나와 똑 같은 능력이 있다는 얘기나 다름없다.”

 

마이크로 소프트의 빌게이츠 가 한말입니다. 그렇습니다. 예전에는 알 수도 없었고, 알지도 못하는 다양한 정보가 지금은 클릭 몇 번으로 알만한 정보, 알고 있는 듯한 지식이 되어 버린 것이지요.

 

예를 들면 제가 초등학생에게 “내일까지 16세기 르네상스 시대의 미술과 문학의 특징에 대해서 정리해서 나에게 알려줘” 라고 숙제를 내리면 하루도 안 걸려서 수백 페이지의 멋진 논문을 만들어 올 수 있는 시대란 말입니다.

이게 정보의 대중화 이지요.

 

정보의 대중화는 모든 사람들에게 기회를 제공하기 까지 했습니다.

이전엔 회계법인이 뭔지 금감원 이 뭐하는 곳인지 로펌은 또 새로나온 음식인지 컨설팅 기업은 또한 어떤 일을 하는 기업인지 알고 싶지도 않았고 알 필요도 없는 위치의 사람들 까지도 이젠 누구나 탐내는 고액연봉이 기다리는 직장이 되었습니다. 또한

MBA는 학부생(ㅡ,.-) 들이 가고 싶어 하는 꿈의 학교가 되었죠.

 

신문에서는 나옵니다. 누구 누구가 이번에 모기업에 상무, 전무가 되었는데 연봉이 얼마더라 .. 부러워라 합니다. 그래서 찾아 보니 보이는 건 학력란 이고 “아~ 명문대 나왔네..역시.. ”,  “와튼스쿨에서 MBA 이수했네~~역시…” 라며 명문대를 나오고 MBA를 이수하면 고액연봉자가 되는 구나 라고 실제 과정과는 반대로 생각해 버리는 실수를 저지르는 듯 합니다.

 

MBA는 중학생이 고등학교 가듯이 혹은 학벌 세탁을 하려고 가는 곳이 아닙니다. 그리고 학부생이 취직을 통한 사회경력이 없는 상태로 가는 일반대학원도 아닙니다.

 

우리가 신문에서 봤던 고액 연봉의 임원이 되는 사람은 사비를 들어서 대학4년 졸업하자 마자 MBA 과정에 들어간 경우는 거의 없다고 봅니다. 기업에서 근무하며 근무성적과 어학성적 우수한 자로 기업측에서 임원(중역)으로써의 적임자로 판단해서 2년에서 길게는 3년이 걸리는 억들어 가는 돈을 써가면서 보내는 것이 MBA입니다.

 

 

단순히 생각해 보십시요

기업경험이 전무한 학생신분의 사람을 MBA 나왔다고 (고액연봉의 예로 들었던...)

증권회사 운용역, 혹은 VC 심사역, 최고의 컨설팅 기업에서 컨설턴트로 쓸 거라고 생각하십니까? (*아니 난 신입사원 혹은 취직이 안되서 그냥 취직만 하는게 꿈이라서… 라고 생각하시면 곤란…)


남의 돈을 맡아서 운용하는 일이 쉽습니까? 펀드 매니저가 대학 졸업해서 일류 증권 회사에 취직 잘하면 바로 된다고 생각하십니까?

용돈관리나 잘 하라고 말 하고 싶습니다. 증권회사가 그 돈 있으면 불우이웃 돕는게 회사에게는 더 큰 이익이 될 겁니다. 조금만 더 클릭질 해보시면 알지만 운용을 맡는(펀드매니져) 분들은 정말이지 증권 회사 내에서도 특수집단에 가까울 만큼 되는 것이 쉽지 않습니다. (무슨 홈트레이딩 하듯 생각하시면…쩝…)

 

 컨설턴트의 자문을 받는 회사나 정부의 사람들이 곱셈을 못하거나 혹은 학벌이 낮아서, 아이디어가 없거나 전략을 못 세워서 그 큰돈을 컨설팅 기업에 줘가면서 자문을 구하는 줄 아십니까?

 

안철수 박사를 비롯한 각국의 수많은 변호사 및 회계사, 기업 사장들이 MBA 스쿨에 앉아서 수업을 듣습니다. 학부 4년 졸업해서 MBA(하이랭킹의 MBA) 바로 갔다고 칩시다

(보통 경력 3년 이상을 요한다) 안철수 박사와 동급생으로 무슨 토론을 하고 싶습니까? 변호사로써 국제무역과 기업 인수합병에 경력을 쌓은 동급생과 서로 얼마나 창조적인 대화가 나눠질까요? (허버드 MBA유학기[아와세 다이스케]책 참조)우수한 성적으로 졸업하지 않으면 처음 직장을 가지려는 자로써는 상당히 불리한 조건임에 틀림 없네요.

 

컨설팅 기업에 취직하겠다고 칩시다.

(고액연봉자 즉, 파트너 급으로써의) 당신이 제공 할 수 있는 당신만의 스페셜한 분야는 뭔가요? 유전공학을 전공하셨나요? 전자공학에 박사이신가요? 회계법인에 회계사로써 혹은 법무법인에 변리사로 경력이 있으신가요? 아니면?? 의지만 있으신 건가요? 혹은 친구들의 고민상담을 많이 들어 줘봐서 잘 할 것 같아서 인가요?

(펀드매니저를 하고 싶다면서 대학 수학점수는 왜 포기해 버리는지…<어이없는 사람 있음>)

 

그렇습니다. 정보가 넘칩니다.

CPA 위에 CFA 가 있고 FRM 이 있다는 것까지 알아 버렸습니다. (위라고 표현한 것은 CFA가 해당분야 경력 5년이상, 3년간의 시험 및 영어시험 이고 지원자격이 대학졸업자 이기에 이렇게 표현 했을 뿐입니다.) 그렇다고 CPA 공부하는 사람에게 “요즘 회계사 너무 많아서 메리트가 없데~”라고 이야기 하는 것은 동물원 침팬지가 웃는 소리 입니다. 본인을 얼마나 가치 있는 세계적인 인재로 착각 하는 겁니까? 명문대 4년 졸업하면 삼성이고 LG고 서로 ‘어서 오십시요’ 라고 반기며 임원으로 고액연봉 계약할 줄 아십니까?

그리고 나는 CFA 할껀데, 넌 고작 CPA 할려고 ? 라고 회사 취직도 아직 안 한 대학생이 할 단계의 말은 아니지요.

 

그럼 알았습니다. 벌써 몇 번의 클릭질로 알아버린 고액연봉의 인재가 될려면 어떻게 해야 할까요?

 

“꿈(생각)은 높게 발은 현실에”

삼성 경제연구소의 표어처럼

취직을 해야 합니다. !!

 

앞에서 언급한 하이 엔드급회사도 좋고 4년 학부 졸업하면 바로 취직을 해야 합니다.

성실성의 잣대인 학점관리도 해야 합니다. 어학을 많이 필요로 하는 회사를 노린다면 영어 점수도 만들어 놔야 합니다. 일단 취직을 한 후에 리더로써의 타의 모법이 되는 모습을 보인 다음에 회삿돈으로 MBA를 가던 뭘 하든 하십시요. (한국학생들은 특이하다 라고 할 정도로 사비유학생 비율이 높다고 합니다.)

 

그 후에 맥킨지든 보스턴 컨설팅 그룹이든 (기존에 다녔던지 새롭게 옮기던지) 재계약을 해서 연봉을 높이는 겁니다.

 

학벌 때문에 차이가 있다고 하시는 분은 자신의 학벌에 맞는 일을 찾으세요. 왜 남의 돈을 맡고 전문지식을 제공하는 하이엔드급 인재가 남들보다는 똑똑해야지요, 억울하거나 욕이 나오면 앞으로 사시면서 더욱 많은 억울한 일과 욕 나오는 일들이 기다리고 있으니 너무 벌써부터 그러시면 안 됩니다.

 

세상에는 똑똑한 사람이 넘칩니다. 80%사람이 본인은 타인이 생각지 못하는걸 생각하고 스스로를 남들보다 똑똑하다고 생각한다고 합니다. 기업의 입장에서 보면 회사문만 나서면 반짝반짝 보석같이 빛나는 우수한 인재들이 수없이 많은 명품매장 진열장에서 바로 당장이라도 팔리길 소원하면서 스스로를 빛내고 있습니다.

 

기업은 정말이지 한 푼의 손해도 입지 않으려고 합니다. 그런 기업이 리스크를 감소하고도 비행기를 타고 사막 한가운데로 날아가 모래알 속에서 반짝이는 진주를 찾길 기대 하는 건, 기업에게도 우리에게도 엄청난 낭비입니다.

 

기업 회장에게 자신을 소개하는 편지를 쓰면 나의 값을 알아봐주셔서 날 믿고 키워 주지 않을까 라고 착각하는 사람도 봤습니다. 과연 읽을 까요? 명품매장이 널린 시대인데!!

 

우리의 선택은 좁아졌습니다.

공채를 통과하기 위해 지금 하고 있는 학과 공부와 자신의 특기를 살릴 수 있는 일에 투자하십시요. 신문기사에 난 소위 잘나가는 사람 학력란 만 보고 “내가 저기만 갔다면” 이라고 후회하는 수십 만명중 한명이 되지 마시길 바랍니다.

 

 

 

참고자료:

일본의 명문대학교의 취직활동 중인 날고 긴다는 일본인 학생들도 평균 30사 지원에 1군데 정도 붙는 정도 입니다. (제미활동 해보신 분이면 아시죠)

그리고 최종면접 까지 가는 수명의 학생들의 출신학교는 거의 6~8개 대학으로 압축됩니다. (국립3,사립3~4) (소위 말하는 최상위 기업의 경우)

꽤 이름있는 학교 출신 일본인의 경우 그런 기업에 들어 가지 못하는 것이 억울하지 않느냐 는 저의 질문에 “당연하다” 라고 생각한답니다.)

한국인 유학생의 경우는? 취직 준비해서 노력한 사람은 취직하고 취직 생각이 없던 사람은 안하는 정도입니다. 학부1학년생들이 착각하는 삼성이나 엘지는 서로 오라고 하는 일은 결코 없습니다.

또 흔히 일어는 본인이 충분하고, +영어를 잘하면 일본에서 취업에 유리할 거란 착각도 많이 하십니다. 하지만 평균 9차 면접까지 하는 심층 면접에서 (그전에 일본학생들과 똑같이 쳐야하는 필기시험을 통과할 정도의 기술 능력은 제쳐두고...) 가장 중요한 것은 논리적인 일본어 구사능력 입니다.


p.s

원본 글에 있는

1. 학벌 2. 어학능력(영어 능력 포함) 3. 적극성

위의 것이 없는 사람은 없다 라고 할 정도로 학력 인플레이션 다 된 사회임을 잊지 마세요.

 

월급 연봉 등 대학별 취직현황이 궁금하시면

2006년 5월 16일
사용자 삽입 이미지


































































































출처 : http://bbs3.worldn.media.daum.net/griffin/do/country/bbs/
read?bbsId=C001&articleId=15598&pageIndex=1&searchKey=&searchValue=
,
<< previous 1 2 3 next >>

티스토리툴바