p2p 프로그램을 자주 돌리는데 단편화율이 45%에 이릅니다. ;; 파티션은 ext3으로 포맷 했습니다.
하드 성능도 많이 떨어져서 하드에서 하드 파일 복사 속도가 10MB/s 밑으로 떨어질 때도 있습니다.
os가 설치된 파티션은 따로 있고 자료 저장용으로 만든 파티션인데 리눅스 조각모음 프로그램을 찾아보면 리눅스에서는 조각모음이 필요 없다는
말만 나오는데 해결 방법이 없을까요?
ext3 용으로 제대로 조각모음을 해 주는 유틸리티는 없다고 합니다.
Shake http://vleu.net/shake/
Defrag http://ck.kolivas.org/apps/defrag/
가 있긴 합니다만 둘 다 디스크가 거의 빈 상태여야 제대로 작동하므로 아마 원하시는 것과는 거리고 좀 있을거라고 생각합니다.
(출처: http://en.wikipedia.org/wiki/Ext3)
정 제대로 된 조각모음을 하고 싶으시면 ext2 로 파티션을 바꾸시거나 (앞으로… 의 이야기입니다만) 일단은 해당 볼륨에서 공간을 좀 비워 보시는게 속도 향상에 그나마 도움이 되지 않을까 합니다.
(그나저나 45% 넘는 fragmentation이라니… 서버급이군요. 후덜덜)
45% 단편화…ext3에서도 그정도 단편화가 나올 수 있군요ㄷㄷㄷ
그나저나 단편화율은 어떻게 알 수 있나요?
단편화율은 fsck로 알 수 있습니다.
[quote:3pmrhuvy]sudo fsck -n /dev/hda1[/quote:3pmrhuvy]
우분투 포럼에서 조각모음 프로그램을 찾았는데 용감하게 돌려 보고 있습니다. 작동은 잘되는군요.
[url:3pmrhuvy]http://ubuntuforums.org/showthread.php?t=169551[/url:3pmrhuvy]
오오…감사합니다… 제 home 폴더가 있는 파티션도 15%나 되네요-_-;; 루트 쪽은 1% 밖에 안되는데…
근데 non-contiguous가 조각화를 의미하는 건가요? 몇가지 검색해보긴 했지만 아직 아리송하군요…
http://forums.fedoraforum.org/showthread.php?t=77582 http://forums.fedoraforum.org/forum/sho ... hp?t=76505찾아본 관련 글입니다. 위에 링크에서는 무려 80%가 non-contiguous라고 나오는데 문제없다고 합니다.
또 아래 글에서는 non-contiguous에 대한 설명이 나오는데
non-contiguous space is not the same as fragmentation,
but fragmentation is in non-contiguous space.
SJ
Actually, fragmentation can be in contiguous space, too.
라고 하네요. -_-;;
2005년 9월에 왜 조각화를 걱정하느냐는 덧글도 함께…(확실히 최신 하드웨어와 대용량 하드디스크를 가지고 있다면… 조각화를 해서 얻을 수 있는 효과보단 조각화에 걸리는 시간이 더 손실이 큰 것 같긴 합니다…)
어쨌든 non-contiguous와 fragmentation은 같지 않은 것 같습니다… 근데 non-contiguous의 의미는 뭘까요? 불연속영역? 하드디스크의 데이터 기록이 띄엄띄엄 되어있는걸 의미하는 걸까요?
netrts님 : 저게 제가 상단에 링크해 놓은 Defrag랑 같은 물건 같군요. 제가 찾은 곳에선 하드 공간이 협소하면 시도하지 말라고 했는데… 결과가 궁금하군요.
bugbear5님: 저 글에서 말하는건 좀 다릅니다.
[quote:2lw3inc2]1. non-contiguous space is not the same as fragmentation,
2. but fragmentation is in non-contiguous space.
3. Actually, fragmentation can be in contiguous space, too. [/quote:2lw3inc2]
이걸 제대로 번역하자면:
- 불연속영역은 단편화를 의미하는건 아니다
- 하지만 단편화는 불연속영역에서 일어난다
- 그리고 단편화는 연속 영역에서도 일어난다.
라는 뜻인데요. 여기서 중요한건 space - 즉, 영역입니다. 자, []으로 감싸진 것이 하나의 영역, 그리고 ()이 파일이라고 합시다. 제가 아는 지식 한에서, 단편화를 | 로 표현하면 위의 말은 각각 이런 경우를 말하는 겁니다.
[code:2lw3inc2]1. [(파일 1)] [( 파 일 2 )] [( 파 일 3 )]
2. [( 파 일 1 |] [|파일 1)] [(파일 2|] [| 파 일 2)]
3. [(파 일 1 |(파일 2 |파일1)| 파 일 2 )]
[/code:2lw3inc2]
1번은 3개의 분리된 영역이 있지만 각각의 나눠진 영역에 파일이 하나씩 온전하게 들어가 있습니다. 고로, 단편화는 없습니다. 2번은 일반적으로 단편화라고 하면 생각하는 - 영역도 불연속적이고 파일 역시 공간을 어설프게 채우다 보니 단편화가 이뤄져 있습니다. 3번은 공간 자체는 연속적입니다만 그 속에서 파일이 단편화가 이뤄져 있는 경우입니다.
즉, 영역의 연속성과 그 속에 있는 데이터의 연속성은 직접적인 연관성이 없다는 말입니다.
각설하고, 멀티테스킹을 하는 OS를 쓰다 보면 파일 하나하나가 연속적으로 곱게 정리되어 있을 순 없습니다. 윈도우즈 쪽에서 말하는 단편화는 여러 파일을 읽고 쓰다보면 필연적으로 일어날 수 밖에 없지요. 하지만 이게 리눅스에서 속도저하와 연결되진 않습니다. 결국 중요한건 디스크 위치에서 어디 있냐는 것 보다 헤드가 그걸 찾는 시간이기 때문에 알고리즘으로 헤드의 움직임을 최소화 해 주면 되는 문제니까요. 이게 잘 되어 있다 보니 리눅스에선 조각모음이 필요없다고 일반적으로 말하는 겁니다.
추신 - 제가 하는 말 중에 틀린게 있으면 언제라도 지적 바랍니다.
수정: 맞춤법… -_-
제가 아는 바로도 Vulpes 님이 설명이 맞습니다만, 이제는 리눅스에서도 단편화를 걱정해야 할 때가 아닌가 싶습니다. netrts 님의 질문을 보면 "p2p 프로그램 사용으로 인한…" 이라고 되어 있고, 토렌트나 e-donkey 사용이 흔한 일임을 감안하면 많은 분들에게 일어날 수 있는 문제이기 때문입니다.
리눅스 자체의 위대함이든, 리눅스가 채택하고 있는 파일 시스템의 우수성이든간에, 이전에는 "리눅스에서도 단편화는 일어나나 우려할만한 수준은 아니다." 라는 것이 정설(?)처럼 여겨져 왔으나, 점점 그건 낭설이 되어갈 가능성이 높아질 것 같네요. p2p 프로그램이 만들어내는 단편화를 시스템적으로 쫓아가기는 벅차 보이니까요.
그리고 이것이 데이터베이스에 집중된 기존 리눅스 시스템과 다른 이유는 데이터베이스는 어차피 작은 파일 read/write 이기 때문에 단편화라는 게 의미가 없기 때문일 것입니다. 저도 위 링크 중 하나의 글을 조금 보았는데, DB 서버에서 해봤으나 소용없더라… 뭐 그런거죠. 제가 DB 전문가는 아니지만 당연한 결과라고 보여집니다. 하지만 p2p 프로그램의 경우, 주 목적이 단일 대용량 파일의 교환에 있고, 이를 자잘한 파일로 쪼개서 받는 것이 일반적인 추세임을 감안하면 하나의 파일이 엄청난 단편으로 구성되어 있을 것을 쉽게 짐작할 수 있습니다. 또한 그로 인해 다른 파일의 단편화를 가속시킨다고 보면(공간은 쓸데없이 낭비해서), 이는 분명 성능에 문제를 야기할 수도 있습니다.
각설하고… 리눅스에서 단편화가 심각하냐… 라든가 조각모음이 필요하냐? 아니냐… 라는 쓰레드는 아닌 것 같네요. ㅎㅎ
그리고
[quote="Vulpes":1by9udnr]즉, 영역의 연속성과 그 속에 있는 데이터의 연속성은 직접적인 연관성이 없다는 말입니다.[/quote:1by9udnr]
라기보다 "비연속적인 영역에서 주로 일어나나, 연속된 영역에서도 일어난다." 라고 보는게 더 맞지 않을까요? 문맥상…
P2P로 인해 Incoming 디렉이 문제라면 다른 파티션으로 이동 후 다시 가져 오는 겁니다.
sudo mv Incoming ???
저도 해보니 4.3 % 정도군요 무지 파일 쓰고 지우는데…
또는 다른 파티션에 파일 다운 을 지정함도 갠찮을 듯 합니다.
[quote="Mr.Dust":3j1h9teg]이제는 리눅스에서도 단편화를 걱정해야 할 때가 아닌가 싶습니다. netrts 님의 질문을 보면 "p2p 프로그램 사용으로 인한…" 이라고 되어 있고, 토렌트나 e-donkey 사용이 흔한 일임을 감안하면 많은 분들에게 일어날 수 있는 문제이기 때문입니다.
리눅스 자체의 위대함이든, 리눅스가 채택하고 있는 파일 시스템의 우수성이든간에, 이전에는 "리눅스에서도 단편화는 일어나나 우려할만한 수준은 아니다." 라는 것이 정설(?)처럼 여겨져 왔으나, 점점 그건 낭설이 되어갈 가능성이 높아질 것 같네요. p2p 프로그램이 만들어내는 단편화를 시스템적으로 쫓아가기는 벅차 보이니까요. [/quote:3j1h9teg]
네, 그런 지적이 있어서 ext4에서는 조각모음을 비롯, 여러가지 관련 이슈를 해소하기 위한 기능을 지원하는걸로 알고 있습니다.
http://en.wikipedia.org/wiki/Ext4[quote="Mr.Dust":3j1h9teg]그리고
[quote="Vulpes":3j1h9teg]즉, 영역의 연속성과 그 속에 있는 데이터의 연속성은 직접적인 연관성이 없다는 말입니다.[/quote:3j1h9teg]
라기보다 "비연속적인 영역에서 주로 일어나나, 연속된 영역에서도 일어난다." 라고 보는게 더 맞지 않을까요? 문맥상…[/quote:3j1h9teg]
아 그 편이 더 의미전달이 부드럽네요. ^^
음… 쓰레드가 제 이해의 범위를 벗어났습니다-_-;; 그래도 답변 감사드립니다…ㅋㅋ
리눅스 데스크탑이 많이 쓰이면서 이제 단편화를 걱정해야 하는 시점이 된것 같네요. 그렇지만 전 조각 모음 자체가 시간낭비라는 생각(이건 어디까지나 제 개인적인 생각입니다)이 있어서 윈도XP에서도 조각모음을 하진 않았으니… 앞으로도 쓸일은 없을 것 같네요.
그러나 리눅스에서는 조각모음이 필요없기 때문에 조각 모음 유틸 자체가 없다는 건 좀 아닌 것 같습니다. 이제 슬슬 조각모음 유틸도 등장하겠네요…=_=
음… 사실 이거 설명할까 말까를 좀 망설였는데…
[b:1rpy5sqf]일상적인 경우[/b:1rpy5sqf], 리눅스에선 정말로 조각모음을 딱히 필요로 하지 않습니다. 비유 곁들여 설명하자면… 요리를 한다고 생각하시고, 조각모음은 부엌을 깨끗이 청소해 놓는 거라고 생각해 봅시다.
지난번의 그림을 약간 재탕하자면…
[code:1rpy5sqf]
1. [(파일 1)] [( 파 일 2 )] [( 파 일 3 )]
2. [(파일 1)(파일4 |( 파 일 2 )|파일4)( 파 일 3 )]
3. [(파일4 |] [|파일4)]
4. [(파 일 1 |(파일 2 |파일1)| 파 일 2 )][/code:1rpy5sqf]
기본적으로 리눅스에선 1과 같은 방법으로 파일을 저장하려고 합니다. 이건 음식재료, 주방기구, 등을 대충 종류별로 놓되 놓은 위치를 다소 듬성듬성하게 하는 것 같기도 한데, 이게 물건을 잡기도 쇱고, 약간 널부러지거나 뭔가가 추가되어도 배치의 변화 없이 대략 그 위치에 놔줄수 있다는 편의성이 있지요.
마찬가지로, 중간중간에 빈 공간을 남겨두는 것은 파일 크기가 변화할때의 여분을 남겨두려는 것도 있고, 질제 디스크는 원형이기 때문에 때로는 중간에 빈 공간이 있는 편이 둘과의 물리적 거리를 줄일수도 있기 때문입니다. 해서, 일반적으로 수십기가의 크기를 가지는 저장공간을 가지는 요즘, 그 10% - 수 기가 정도의 공간만 남겨 놓으면 큰 단편화 없이 파일을 저장할 수 있게 됩니다 (일반적으로 취급하는 파일 크기가 커봤자 1기가 전후이므로). 대신 이럴 경우 군데군데 빈 공간이 남게 되어 버릴테니까 당연히 위에서 말했던 비연속 공간은 많아지게 됩니다. 저장된 공간/빈공간/저장된 공간… 이런 식으로 계속 반복될테니까요. 하지만 단편화는 거의 일어나지 않습니다.
문제는 그 마지막 여분의 공간을 활용하기 시작하면 이제 그 듬성듬성한 공간을 활용해야 합니다. 최대한 연속된 공간을 만들려고는 하겠지만 (이건 좀있다 다시 설명을…) 그럼 2와 같은 형태를 띄기 시작하곘죠. 파일 4를 읽기 위해서 파일 2 구간을 뛰어 넘어야 하고… 하는 식의 데이터 단편화는 일어났습니다만 영역 자체는 중간에 빈 공간 없이 이어지고 있습니다. 즉, contiguous 공간이란 소리죠. 여기서 온전한 파일들이 지워지고 하면 3의 형태가 나올겁니다. 이게 구간도 비연속이고 데이터도 단편화되어 있죠. 여기에 또 파일을 쓰고 하면 4의 형태도 나올수 있는거죠. 실제 꽤 오랜 기간 빡빡하게 쓴 드라이브는 1~4의 유형이 다 보일겁니다.
요리하다 다 쓴 양념통을 빼서 딴데 놓고 다른 식재로 갖다놓고 반쯤 완성된건 또 공간을 좀 만들어서 놔두고… 하다 보면 물건들의 배치가 난잡해 지는거랑 같은 이치지요.
그럼에도 불구하고 별 필요가 없다고 하는 것은 첫째로 알아보기 쉬우시라고 위에 그림을 저렇게 해 놨지만 실제로는 될 수 있으면 효울적으로 재배치도 합니다. 한번 어느 장소에 저장되었다고 게속 그 위치만 물리적으로 차지하고 있는건 아니란 거죠. 큰 빈 공간이 필요하면 다른 파일들을 조금씩 움직여서 연결된 공간을 만들어내고 하기에 데이터 단편화는 생각보다 덜 일어납니다.
즉, 갑자기 큰 냄비를 하나 놔야 한다면 듬성듬성 놓인 물건들의 배치를 조금씩 바꿔서 크게 배치를 바꾸지 않고서도 냄비를 올려놓을 수 있는 공간을 만들 수 있는 이치랑 같달까요.
그리고 두번째는 어차피 멀티테스킹을 하는 OS기 때문입니다. 말 그대로 여러개의(Multi) 일(Task) 을 한꺼번에 하고 있고, 당연히 그만큼 여러 파일을 쓰고 읽고 지우고 변경하고 합니다. 하지만 이걸 처리하는 프로세서는 그 일의 개수에 훨씬 못미치죠. 그걸 해결하기 위해 한가지 일을 다 할때까지 다른게 기다리는 식이 아니라 여러개의 task들이 시간제로 공유하는 방식을 택합니다. 당연히 파일들도 그렇게 억세스되겠죠? 이 말은 설사 물리적으로 완벽하게 조각모음을 해 놔도 무슨 프로세스가 들아가고 있느냐에 따라 헤드는 이쪽 끝에서 저쪽 끝으로 사정없이 옮겨가야 할 수가 있다는 겁니다. 이게 논리적인 단편화입니다. 저도 자세히는 모르지만 이걸 처리함에 있어서 효율적이기에 실제로 헤드는 별로 안 돌아다니고도 원하는 데이터를 읽어 들일 수 있게 되는 겁니다.
뭔가 복잡한 요리를 하는데 항상 소금쓰고 제자리 뭐 쓰고 제자리 하면 그 사이에 없어지는 시간이 꽤 되겠지요? 이게 가정집의 규모라면 별 상관없을지도 모르지만 여러 손님이 들어오는 음식점이라고 생각해 봅시다. 리눅스는 조미료랑 주망기구를 다소 널부러지더라도 손에 닿기 쉽게 해 놓는 겁니다. 동선을 줄이는 거죠.
물론 이게 너무 과도하게 심해지면 한번 주방을 싹 치워야 합니다. 하지만 어지간하지 않고선 (위생은 논외로 하구요 ㅋ) 그럴 필요가 없게 됩니다. 집고 놓고 하는 사이에 그 위치가 자연스럽게 되고 작업은 빨라지니까요. 이걸 하는 재주가 리눅스가 좋기에 조각모음을 잘 안해줘도 된다고 하는 겁니다. 그래서 ext2에건 가능했던 기능이 ext3에서 빠진 걸테구요 (이건 저만의 추측입니다만) 애초에 이 능력이 떨어지는 (떨어진다고 하는… 이려나요. 사실 깊이있게 윈도우즈쪽을 파고 들어간건 아니라서) 윈도우즈에서 생기는 파일 단편화랑은 의미를 달리한다고 합니다. 다만, 님과 같은 경우가 이제 많이 생기고 있기 때문에 다시 ext4에서는 조각모음을 다시 넣는게 아닌가 하고 생각합니다.
죄송합니다 어제 잠을 제대로 못자서 여기서 일단…
다시 말씀드리지만 이건 어디까지나 저 스스로의 이해된 내용을 바탕으로 쓴 글이라 잘못 알고 적은 내용이 있을수 있습니다. 지적사항 있으면 언제든 부탁드립니다.
답변 감사합니다. 우분투포럼에서 받은 프로그램을 돌리고 non-contiguous가 6%로 줄어 들었습니다.
Vulpes님이 올린 자료와는 다른 프로그램인 것 같습니다. xfs 조각모음 알고리즘을 사용했다고 하는데
버전이 0.1밖에 안되고 아직 실험적인 프로그램인 것 같아요. 프로그램의 기능도 단순 파일 조각모음만
가능하고 시간도 무지 오래 걸립니다. 그래도 하드 전송속도가 정상적으로 돌아와서 다행이라 생각합니다.
답변 주신분들 모두 감사합니다.
[quote="강분도":2y18btzd]P2P로 인해 Incoming 디렉이 문제라면 다른 파티션으로 이동 후 다시 가져 오는 겁니다.
sudo mv Incoming ???
저도 해보니 4.3 % 정도군요 무지 파일 쓰고 지우는데…
또는 다른 파티션에 파일 다운 을 지정함도 갠찮을 듯 합니다.[/quote:2y18btzd]
저도 이 방식을 추천합니다.
읽고 쓰기가 많은 파일 저장용 파티션을 따로 두는게 좋을 것 같네요.