레이드로 일반하드 두개를 물려 적절한? 성능을 보여줬습니다
파티션을 그냥 소프트웨어로 잡으면 균일하게 잡는걸로 아는데
콘트롤러에서 나누면 외각에 2~30%[가장 빠른부분]를 c드라이브로 잡아
하드디스크 벤치마크에서도 그래프가 내려가는게 거의 없을 정도로 세팅이 된다고 했습니다
[실재 그래프 캡쳐사진을 봐도 끝에서 살짝 내려가는 것 빼곤 지그재그이지만 평균적으로 수평을 유지했습니다]
지금 제가 사용하는 콘트롤러는 인텔 SRCSAS144E RAID Controller입니다
이전에 모회원님에 도움을 받아 매뉴얼을 다운받았지만 영문이라 도통 모르겠네요
[영어에 많이 약합니다...쏟아지는 영문보면 어질어질할 정도입니다]
콘트롤러안 매뉴에서도 이것저것 만져봤지만 이건가 저건가 하는 수준입니다
OS 에서 파티션을 잡으면 하드가 몇개건 항상 외각쪽으로 먼저 생기는걸로 알고 있습니다.
엑세스타임도 좋아보이지만 HD튠의 엑세스타임은 전체평균입니다.
통으로 재면 빠른 앞부분과 느린 뒷부분 전부를 측정해서 평균내지만 앞부분만 잘라 테스트하면 앞부분만 테스트하고 느린 뒷부분을 제외하니 빨라 보입니다. 이때 랩터랑 엑세스타임이 비슷해보이지만 렙터도 마찬가지로 앞부분만 테스트하면 더빠르니 절때 렙터보다 빠른게 아닙니다.
흔히 말하는 앞자르기한다고 성능이 좋아 지는게 아닙니다.
앞자르기한다면 그부분에 OS가 설치되어 뒷부분까지 OS파일이 넘어가지 않도록 하는게 중요합니다.
통으로 OS 프로그램 데이터 한꺼번에 이용한다면 나중에되면 OS 프로그램이 앞부분 뒷부분 흩어지는데 이걸 방지해서 성능 하락을 막는것입니다.
앞자르기하는건 숫자놀이의 전형입니다.
오버클럭해서 올리는건 성능이라도 올라가지만 앞자르기는 꼼수로 숫자를 올릴뿐입니다.
그냥 파티션으로 나누셔도 됩니다.
저용량하드(20기가짜리 4개)들을 묶어서 80기가로 만들었고,
이것을 리눅스에 붙였습니다.
이렇게 묶여진 하드들(레이드0)은 ext3 / swap으로 구분 <---파티션으로 나눠서 쓰고 있습니다.
레이드에서도 파티션이 나눠진다는 의미아닌가요?
다운로드 파일만 담으려고 합니다 36기가 랩터4개 레이드0로 묶어 파티션 잡으면 130기가 정도 나오는데 이 중 45기가만 앞부분 잡아 c드라이브로 윈도우 돌릴 생각입니다
벤치같은건 상관없습니다 전 그냥 4개 하드의 묶은 성능을 최대치로 뽑아서 사용하고 싶은것입니다
다만 보드자체가 IDE는 레이드지원하는게 드물뿐더러, IDE커넥터에서 레이드를 하기 위해 ODD를 달지 않고, PM/PS, SM/SS부분에 모두 하드를 달아서 레이드를 할 경우에...성능향상이라기보다... IDE커넥터를 이용하여 레이드를 활용할 때보단 좀 낫다.정도의 수준으로 생각하시면 될 거 같습니다.
인텔RAID카드를 비롯한 거의 대부분의 RAID카드에는 볼륨을 나눌 수 있는 기능이 있습니다.
NTFS나 EXT3등의 특정 파티션으로 나누지는 못하지만, 볼륨은 나눌 수 있습니다.
볼륨을 나누게 되면 윈도우의 디스크관리자에서 별개의 디스크로 보입니다.
즉, 파티션보다는 한단계 위(좀더 하드웨어적인..)의 개념이라고 할까요...
그리고 억세스타임은 하드디스크의 안쪽이 빠르지만 전송속도는 디스크의 바깥쪽이 빠를거 같네요.
2. 보통 엑세스타임이라고 부르는 접근시간은 데이터 분포 위치에 따라, 혹은 디스크 전반에 걸쳐 다소 차이가 납니다. 제조사 명시 접근시간은 평균접근 시간입니다. 벤치마크에서 측정된 값은 벤치 구간의 평균값입니다.
3. 트랙간 탐색시간은 디스크 외주와 내주에서 미세한 차이가 있을 수 있지만, 섹터의 접근은 외주나 내주나 각속도가 동일하기 때문에 동등합니다.
4. 벤치마킹 툴의 벤치 로직에 따라 달라지지만, 일반적으로 접근시간과 전송성능을 따로 놓고 보는데...
전송성능 안에는 접근시간의 몫도 포함하고 있습니다.
연속읽기에서 99.2MB/s 전송성능으로 기록하고 접근시간이 8ms로 측정된다면 992ms동안 99.2MB전송 되었다고 보시면 됩니다. 1ms당 100KB전송한 결과이지만 실제 100KB짜리 파일 전송에는 9ms(접근에 8ms)가 소모될 것입니다.
5. 앞부분을 잘라서 사용하면 이론적으로 속도 이득이 있습니다.
그러나, 문제는 OS설치 파티션의 경우 앞부분을 잘라 쓰지 않더라도 대부분 OS의 시스템 파일들은 포맷 후 설치되므로 디스크의 앞부분을 차지합니다.
그러므로 파일 로딩 자체에는 앞부분을 별도로 사용한다고해서 별 이득이 생기지 않을 것입니다.
그렇다면, 시스템 파일들 이외의 임시 파일들의 속도 이득을 생각해보아야하는데...
대체로 임시 파일들은 크기가 작은 편입니다. 크기가 작은 파일들은 4번에서 예시했지만 접근에 걸리는 시간대비 전송에 걸리는 시간이 미비하여 여러 파일들에 동시 접근이 일어나고, 해당 파일들이 순서대로 정렬되어 있다면 모르지만
그렇지 않다면 마찬가지 체감 효과는 미비할 것입니다.
임시파일들은 그 특성상 로딩 혹은 기록에 필요한 순서대로 정렬되어 있을 가능성은 0%에 가까운 이유입니다.
덩치가 큰 페이징 파일 등은 다소 이득이 있을 수 있을 것입니다. OS설치 와는 별도의 목적이라면 상황에 따라 다를 수 있습니다.
그냥 느린 내주 부분을 버리고 속도 이득을 꽤하겠다는 생각이면 굳이 볼륨이나 파티션을 사용하지 않아도 그 이상의 공간을 사용하지 않으면 어짜피 동일 용량안에서의 속도는 동일하기에 상관없는 문제가 되겠지요.
6. 그러나 OS 설치 파티션을 나누는 것은 디스크 전반적으로 프래그먼트를 줄이는 방법이 될 수 있고 관리나 여타의 목적으로 상기의 이유와 상관없이 시스템 전반적으로 속도에 약간은 기여를 할 수 있습니다.
여담이지만, 저는 OS설치 목적으로 SSD를 사용하는 것에 반대인 입장인데요.
SSD 정도에 투자를 할 만큼 고급유저라면 상시 떠 있는 프로그램이 많은 편일테고 대부분의 시스템 공통 DLL은 이미 로딩되어 있는 상황이 대부분입니다. 단지 부팅 속도 개선이 목적이 아닌 경우라면 그다지 큰 득을 본다고 생각하긴 어렵다고 봅니다. 물론 금전적인 제한이 없다면 모르지만 현재까지 접근 가능한 수준의 SSD들이 다량의 작은 파일 접근시 문제가 있는 점을 감안한다면 임시 파일 용도로도 더더욱 램디스크가 더 나을 수 있구요.
100% 정확한건 아니겠지만 고려하시는 부분 도움이 되었으면 합니다.
없던 속도 이득이 생기는게 아니라 원래 앞부분이 전송 성능이 좋으니까 당연히 그렇다는 것이지요.
그 용도가 일반적으로 위와 같다면 별 득이 없다는걸 설명한 것이구요.
전송성능이 필요한 하드레코딩 등에서 임시 저장용도 같은 것에 첫파티션을 활용한다면 득이 생길 수 있겠지요.