Windows 7 이것저것 by object

윈도우 7을 쓰면서 느낀 단점과 장점 몇 가지 정리. 예전부터 종종 써놓은 것을 한번에 다 올림.

 

1. 향상된 데스크탑 관리 기능

윈도우 7의 킬러(…) 기능. 노트북도 그렇고 데스크탑 모니터는 이제 대부분 와이드 모니터다. 와이드 모니터를 사용하다 보면 매우 빈번히 두 프로그램을 나란히 놓고 작업할 때가 많다. 윈도우 7은 윈도우 창을 끌고 모니터 오른쪽/왼쪽 가장자리로 이동시키면 밀면 자동으로 모니터 반만 차지하도록 된다. 단축키는 Win + ←/→. Shift를 누르면 듀얼 모니터로 넘어간다. 문서 두 개 열어놓고 작업할 때 정말 편리하다.

비슷한 기능이 또 있다. 윈도우 가장 자리로 마우스를 대면 ↕(아래위 화살표)가 뜬다. 여기서 더블 클릭하면 창이 상하로만 최대화 된다. 아니면, ↕ 커서를 드래그해서 모니터 윗쪽으로 옮겨도 그렇게 된다. 일반적으로 프로그램은 가로폭보다 세로폭이 부족하기 때문에 이것 역시 꽤 편리하다. 수직 방향 최대화의 키보드 단축키는 Win+Shift+↑. 반대로 Win+Shift+↓는 수직 방향 최대화 취소.

창의 최대화와 최소화 키보드 단축키는 이전까지는 Alt+Space로 메뉴를 띄우고, X/N/R 같은 걸 눌러야 했다. 그런데 이제 Win+↑로 바로 최대화, Win+↓로 바로 최소화가 된다. 윈도우 키 누르고 + 혹은 –를 누르면 재밌는 기능이 바로 뜨기도 한다. 윈도우 7의 새로운 단축키 리스트는 여기를 참고. 운영체제 끼리 비교는 여기를 참고.

 

2. 프로그램 미리보기 기능

비스타부터 데스크탑 그래픽 엔진이 XP와 판이하게 바뀌면서 태스크 바의 아이콘에 커서만 갖다 놓아도 해당 프로그램의 프리뷰나 동영상 움직이는 것도 볼 수 있다. 이거 생각보다 무지 귀엽고 재미있는 기능이다. 윈도우 7은 태스크바가 많이 바뀌면서 이제 이 프리뷰에서 바로 재생/정지, 앞 뒤 탐색도 가능해졌다. 윈도우 미플이나 iTunes 최신 버전은 이 기능이 지원된다.

그런데 문제점이 하나 있다. 이건 비스타 시절부터 온 것인데, 아래 그림처럼 어떤 프로그램은 프리뷰가 작동하지 않을 때가 있다. 보면 프리뷰가 그냥 회색이고 프로그램 아이콘만 덩그러니 떠있다.

과거 윈도우는 윈도우 창이 최소화되면 메모리를 아끼고자 최소화된 프로그램의 메모리를 시스템으로 반환하도록 하는 정책을 썼었다. 윈도우 비스타나 7은 많은 램을 가정하고 만들어진 것이라 이 정책이 그대로 적용되는 것 같지는 않다. 그런데 여전히 하나 문제가 있다면, 어떤 프로그램을 오랜 시간 동안 쓰지 않고 놓아두면 그만 프리뷰를 잃어버린다. 이런 프로그램을 다시 활성화 한번 전체 창이 그려지게 하면 다시 프리뷰가 복구된다. 프로그램을 오랜 시간 동안 안 썼다고 굳이 각 프로그램의 프리뷰(Taskbar API는 Thumbnail이라고 부름)까지 삭제할 필요가 있을까? 옥의 티라고 하기에는 나로서는 꽤 불편하다.

 

3. 강화된 검색 기능 (Window Search)

알마 전 외국 뉴스를 보니 윈도우 7 사용자가 느끼는 불편함 중에 하나가 “윈도우 탐색기가 파일 확장자를 보여주지 않는 것”이라고 했다. 다소 어리둥절한데 이건 지금까지 모든 윈도우 클라이언트 버전이 그래왔다. XP도 디폴트 값으로 탐색기에서 파일 확장자를 보여주지 않는다. 사용자가 직접 옵션을 고쳐야 한다.

그런데 윈도우 비스타부터 강화된 탐색 기능은 이럴 때 무척 편리하다. 7은 더욱 강화되었다. 만약 파일 확장자를 보여주고 싶다면 힘들게 옵션이 어디 있는지 삽질할 필요가 없다. 그냥 시작 메뉴에서 검색하면 된다.

위 그림처럼 그냥 “file extens” 정도만 치면 된다. 위에 선택되어있는 “Show or hide file extensions”에 가서 옵션 바꿔주면 된다. 키보드로 치는 것이 컴퓨터 초보자에게는 사실 쉽지 않은 일이나 익숙하신 분에게는 이게 무척 편리할 것이다. 특히 제어판의 옵션 중 어디 있는지 몰라 삽질할 필요가 거의 없다. 비스타 때는 검색 중에 잘 안 되는 것이 있었는데 7은 더 강화가 되었다. 제어판을 열고 아이콘 뒤지는 일을 이제 더 이상 할 필요 없다.

그리고 이것도 비스타부터 된 것인데 모르는 사람이 많은 것 같다. Launchy 같은 허접한 프로그램을 쓸 이유도 전혀 없다. 맥만 되는 것이 아니라 비스타부터 기본으로 a p만 쳐도 Adobe Photoshop이 뜬다.

혹시 SSD를 쓰시거나 또 데스크탑 검색을 많이 쓰는 사람은 윈도우 자체적인 Windows Search 기능을 최대한으로 이용하면 좋다. SSD 사용 팁에는 이 기능을 끄라고 오히려 조언하는데 나는 완전히 정반대이다. 데스크탑 검색, 특히 PDF 내까지 검색하고 싶을 때는 이거 정말 편하다. 아래 그림처럼, 나는 C, D, E 드라이브를 완전히 검색해놓고 있다. 40만개가 넘는 파일이 인덱싱 되면 내 컴퓨터 전체에서 문서 찾는 것이 너무 편하다. 하드디스크를 쓸 때는 그래도 검색어 당 5초 이상이 걸렸는데, SSD를 쓰면 이게 2~3초 내로 거의 다 된다. 끝내 준다..

이 인덱스 설정 창도 그냥 윈도우 시작 검색 창에서 “index”만 치면 된다. 42만개 파일을 인덱싱 하면 약 1.8GB 정도 인덱스 파일이 생긴다. 용량 적은 SSD에서는 아까울 수도 있지만 나는 기꺼이 쓴다. 다만 윈도우 64비트에서는 기본적으로는 PDF 문서 내가 인덱싱 되지 않는 버그가 있다.

 

doc 같은 파일은 자체적으로 필터가 있어서 파일 명과 파일 속성 뿐만 아니라 문서까지 당연히 검색해준다. 그런데 PDF는 64비트 윈도우에서 이게 안 되어 난감했었는데 보니까 버그였다. 다행히 Adobe에서 별도의 플러그인을 배포하고 있으므로 이거 깔면 해결된다. (아래아 한글은… 이런 거 없다. 파일 자체를 공개 안 하는데…)

구글 검색 결과처럼 똑똑하게 정렬되어 오는 것 같지는 않지만, 그래도 PDF 문서를 내용으로 순식간에 찾는 건 정말 편한 일이다. 나 같이 별도의 데스크탑 서치 프로그램 까는 걸 싫어 하는 사람에겐 아주 좋다.

요즘 탐색기 열고 폴더 뒤지는 일이 사라졌다. 그냥 검색해버린다. 그런데 다시 말하지만 SSD가 있어야 가능한 일. SSD의 랜덤 읽기/쓰기는 하드디스크보다 수십 배, 혹은 100배 이상 빨라서 가능한 일. 단, 싸구려 SSD는 제외.

 

4. 강화된 백업 기능

솔직히 고백하자면 지난 12년 간 백업다운 백업을 해 본 적이 없다. 중요한 소스 파일은 다 SVN에 저장되어 특별히 할 필요 없었다. 정말 중요한 일부 문서만 살짝 백업했지 체계적인 백업 시스템을 구축한 적이 없었다. 대신 나는 하드디스크를 2년 이상 쓰지 않고 새것으로 바꾸므로 하드디스크 고장을 겪은 적이 없기는 했다. 그러나 이제 SSD를 RAID0으로 쓰고 또 얼마 전 Western Digital의 1.5TB 하드디스크 사자마자 고장 나는 걸 겪은 뒤에 생각이 바뀌었다. 수백 기가 되는 사진과 동영상도 이제 최소 한 군데 백업을 두고 있다. 어떻게 백업을 할까 고민을 많이 했는데, 완벽하지는 않지만 윈도우 7의 백업 기능은 꽤 쓸만하다. 사용 방법은 매우 직관적이다.

그런데 그냥 윈도우 기본 기능이다 보니 아쉬운 부분이 많다. 일단, 특정 파일명 같은 걸 백업 시 제외하는 기능이 없다. 소스 코드 컴파일하면 .obj, .pch 같은 파일이 많은데 이것까지 하는 수없이 같이 백업된다. 또, 가장 아쉬운 것은 여러 군데 백업하는 것이 불가능하다. 다시 말해 “어떤 파일을 언제 어디로 백업하라” 라는 인스턴스를 하나 밖에 만들지 못한다. 어떤 폴더는 S드라이브로 어떤 폴더는 T드라이브로 하고 싶은데 이게 안 된다. 다른 계정으로 만들어서 백업 하면 안되나 싶었는데, 백업은 시스템 차원인지라 이렇게도 안 됨.

별도의 사진은 넣지 않았는데, 시스템 이미지 복구는 노턴 고스트나 아크로니스의 트루이미지의 그 기능이다. C드라이브 이미지를 그대로 저장할 수 있다. 윈도우 DVD로 부팅해 복구 모드로 들어가면 이미지를 살릴 수 있다. 그러나 이것도 자유도가 높지 않다. 생성된 이미지를 아무런 파티션에 넣을 수가 없는 것 같다. 오직 하드디스크 구성이 같을 때만 되는 기능 제약이 있다. 그냥 Hiren Boot CD를 쓰는 것이 여전히 가장 편한 선택. 윈도우 기본 기능 치고는 썩 괜찮으나 다른 백업 소프트웨어도 먹고 살아야 하기 때문에 아주 미니멀한 기능만 제공하고 있다.

 

5. SSD에 최적화된 운영체제

정말 SSD는 컴퓨터를 완전히 다른 녀석으로 바꾸어 놓을 수 있다. 컴퓨터 업그레이드 하고 싶으면 무조건 SSD 하나 사면 된다. (그런데 제발 허접한 SSD 사면 안되고 OCZ나 인텔 것만 사세요) 특히 RAID0으로 두 개 정도 묶어 쓰면 이건 환상적이다. 부팅 시간이 25초를 넘지 않는다. 윈도우 바탕화면이 뜨고도 보통 한참 버벅이는데 그런 거 없다. 그냥 바탕화면 보이자마자 탐색기와 브라우저 열면 즉각 반응한다. 포토샵 띄우는데 3~4초 걸린다. 위에서 말한 탐색 기능 역시 SSD가 주는 큰 행복이다. 폴더 뒤질 필요가 없다. 그냥 검색하면 끝.

그런데 SSD에게도 숙제가 산적하다. 특히 SSD는 쓰기 수명이 꽤 짧다. 그렇다고 하더라도 일반 사용자가 보여주는 쓰기 패턴으로는 5년은 버틴다. 일반 SSD로 쓰이는 MLC는 약 5천에서 1만 번 지울 수 있다. 일반 사용자의 쓰기 패턴이라면 5년 이상은 충분히 쓰리라 예상된다. 쓰기 수명은 짧지만 오히려 내구성은 하드디스크 보다 월등이 높으므로 하드디스크보다 안정성이 떨어진다는 일부 사람들의 주장에는 동의하기 어렵다.

이런 쓰기 횟수의 제한으로 기존의 운영체제의 정책 중 바뀌어야 하는 부분이 많다. 특히 디스크 조각 모음은 써서는 안 된다. 왜냐면 순차 쓰기라 하더라도 이게 실제 SSD 내로 가면 완전 랜덤하게 분포되기 때문이다. 전혀 디스크 조각 모음(하드디스크 상의 조각난 파일을 모아 읽기 대역폭을 늘리는 것이 목적)을 SSD는 할 필요가 없다. 윈도우 비스타부터 자동으로 조각 모음을 한다. 그래서 명시적으로 조각 모음을 할 필요가 사실 없었다. 그런데 윈도우 7은 SSD 하드디스크를 자동으로 디스크 조각 모음을 실시하지 않는다. 맥 운영체제는 조각 모음이 필요 없다고 생각하는 사람이 많은데, 그냥 백그라운드로 진행되어서 그런 것일 뿐. SSD를 쓴다면 이 조각모음도 끄는 것이 좋다.

임시파일 폴더(TEMP, TMP 환경 변수)와 인터넷 임시 폴더는 SSD에 안 쓰는 것이 좋다. 요즘 램 값이 올랐다고 하더라도 무지 싸다. 나는 램 디스크에 모든 임시파일과 인터넷 임시 폴더를 할당해서 쓰고 있다. 1GB 정도 램 디스크 잡아주면 아주 큰 문제 없이 사용할 수 있다. (간혹 어떤 무식한 프로그램은 압축 푸는 것 같은 일을 죄다 임시 폴더에서 하려고 해서 1GB가 부족하다고 안 될 때가 있기는 하다.)

일반적인 하드디스크(WD 2TB) 대역폭

인텔 X25-M 80GB 2세대 성능 (파코즈에서 가져왔음)

인텔 X25-M 80GB 2세대 3개를 RAID0으로 함. Write-back 캐시 켰음. 그런데 몇 주만 사용하고 성능 측정하면 상당히 대역폭이 떨어짐. 750MB/s는 거의 500MB/s로 줄어듬. 랜덤 쓰기도 절반으로 뚝… ㅠㅠ

윈도우 7은 현재로서 유일하게 TRIM이라는 기능을 지원한다. SSD의 가장 큰 단점은 시간이 지날수록 쓰기/읽기 대역폭이 감소한다는 점. SSD는 쓰기 수명 제한으로 웨어 레벨링(wear-leveling)을 필수로 한다. 특정 물리 디스크 블록의 쓰기 횟수를 기록하여 어느 한 블록이 과다하게 쓰여지는 것을 막도록 한다. 그런데 이 기능 때문에 파일을 삭제하더라도 SSD는 정확하게 어떤 지점이 정말로 삭제되어있는지 알기 어렵다고 한다. 그래서 명시적으로 운영체제가 파일 삭제나 포맷 시 이 정보를 알려 주어야 한다. 이 명령을 TRIM이라고 하는데, 현재로서는 윈도우 7만이 지원한다. 리눅스는 완벽히 지원 안 한다고 하고 맥은 이야기 없다. 그러나 RAID에서는 아직 TRIM이 안 된다!!! 대역폭 하락이 심함.

 

6. 기타 잡담

  • AVCHD라는 HD 캠코더에서 쓰이는 포맷이 있다. 이걸 재생하기가 예전에는 쉽지 않았다. 그런데 윈도우 7은 AVCHD를 기본으로 지원한다!! 윈미플에서 m2ts 파일이 그냥 아주 잘 열린다. 당연히 미리보기도 된다.
  • 배경 화면이 자동으로 바뀌는 기능 아주 맘에 든다.
  • 비스타의 사이드바가 그리울 때가 많다. 자유롭게 떠다니는 가젯이 불편할 때가 꽤 있다.
  • 비스타에 있던 메모장 가젯이 사라졌다. 7의 Stikcy Notes를 쓰라는 뜻인데 왜 굳이 없앴을까. 그래도 구글링 검색해서 비스타의 메모장 가젯을 가져와 쓴다. 비스타에 있던 주식시세 보기 가젯도 안 된다. 무슨 사용자 동의 문제로 사라졌다는데 역시 구글링하고 윈도우 사이드바 파일을 예전 걸로 교체해서 다시 살림.
  • 레지스트리 키의 보안이 한층 강화되어 마음대로 삭제 안 되는 경우가 있다. 직접 레지스트리 키의 권한을 수정 해야만 한다. 예를 들어, zip 폴더 미리 보기 끄려면 약간 삽질이 더 필요하다.
  • 나는 그 어떠한 안티 바이러스 프로그램도 쓰지 않는다. 이런 말 했더니 누군가 너 컴퓨터 바이러스 있을 거야 라고 겁을 줘서 프로그램 깔고 검색해봤지만 하나도 없었다. 당연하다. 아무런 첨부 파일이나 외부에서 다운 받은 파일만 안 열면 된다. 소프트웨어 취약성을 노린 악성 코드가 작동할 수도 있으나 64비트 운영체제는 컴퓨터는 이런 면에서 다소 안전하다. 그냥 늘 보안 업데이트하고 엄한 첨부 파일 안 열면 된다.
  • 얼마 전에 우연히 터득한 팁. CMD 창에서 현재 폴더의 탐색기를 바로 띄우고 싶다면… 아래 그림처럼.

 

 

세 줄 요약:

  • 아직도 Windows XP에 Visual C++ 6.0으로 개발하십니까?
  • 이제는 바꾸셔도 됩니다.
  • 2010년대가 열렸습니다.

(예전에 VC++ 6.0을 좀 쓰지 말자고 글 올렸다가 욕 많이 먹었는데, 이건 강요나 전도하는 글이 아닙니다.)


덧글

  • 몽몽이 2010/01/09 11:33 # 답글

    Windows 7을 직접 써 보진 않았지만 유사 기능을 해 주는 XP용 프로그램을 써 봤는데
    결국 프리뷰가 안 나오는 것들이 있어서 안 쓰게 되더군요.
    그런데 그런 버그성이 아니라도 프리뷰가 오래 되면 없애야 하는게 있기는 할 것 같습니다.
    어떤 프로그램은 화면이 현재 상태를 보여주지 않으면 큰 오해를 하게 되는 것도 있으니까요.
    프리뷰를 지우는 대신 흐려지게 만든다든지 뭐 그런 식으로 보강되어야 할 것 같기는 한데 애매하네요...
  • object 2010/01/09 12:36 #

    좋은 생각입니다. 그런데 적어도 아예 없어지는 것은 좀 문제가 있다고 봐요;;
  • lefoot 2010/01/09 11:55 # 답글

    좋은 글 잘 보았습니다 ^^ 몇가지 첨언을 하자면, TRIM 커맨드가 ATA 표준에 추가된 것은 굉장히 긍정적이라고 봅니다. SSD의 경우, 두개의 write request가 동일한 주소 X에 도달할 때까지는 해당 블럭이 "살아있다"라고 최대한 conservative한 가정을 해야합니다. 따라서 운이 없으면, OS로부터 도달하는 write request에 synchronous하게 garbage collection(블럭레벨의 GC입니다 ^^;)을 수행해야 하는 경우가 생기므로 response time이 급작스럽게 늘어나는 문제가 때때로 발생하게 됩니다. SSD를 쓰신 분들중에서 freezing 현상이 가끔 보인다라고 하는 것은, 이런 문제일 가능성이 꽤 크다고 보여집니다(아직 공표된 결과는 못봤습니다만...). OS가, 자신이 특정 파일을 삭제했고 그 파일이 소유했던 블럭 주소들을 TRIM 커맨드로 SSD에 알려주면, SSD는 그 정보를 GC에서 미리 활용할 수 있게 됩니다. 말하자면, TRIM 덕분에 좀더 공격적으로 asynchronous하게 free block들을 확보할 수 있게 된다고 볼 수 있을 것 같습니다. 물론, 워크로드 자체가 file rewrite이 빈번하게 발생하는 경우라고 한다면, TRIM으로 얻는 이득이 미미할 수도 있겠군요. Disk 분야는 학자들이 "특정 커맨드를 추가해야 한다"라고 줄기차게 주장을 해도, 업체에서 잘 움직이지 않는 경우가 많았는데요, SSD는 초기라 그런지 인터페이스 확장에 매우 적극적인 움직임을 보이는 것 같습니다. 아, 그리고 펌웨어 업데이트는 하셨는지요? OS도 TRIM 커맨드를 dispatch할 수 있도록 구현되어야 하지만, SSD 역시 TRIM 기능을 이해하고 있어야 합니다. 때문에 예전에 나온 디바이스라면 펌웨어를 업데이트 해야만 하는 것인데요, 얼마전 인텔에서 발표한 펌웨어가 안정성 문제로 SSD가 벽돌이 되는 경우가 목격되었다고 하는데요; 이문제는 최근에 고쳐졌는지 모르겠네요. ( http://www.kbench.com/hardware/?no=77112&cc=0 )
  • object 2010/01/09 12:30 #

    오.. 역시 전문가는 다르시군요. 감사합니다. 사람들이 GC.. GC.. 그러는데 역시나 가비지 컬렉터군요. 아직까지 프리징을 겪은 적은 전혀 없습니다. 80GB 3개 묶어서 240GB로 쓰는데 괜찮습니다.

    네, 당연히 펌업 다 했고요. 요즘은 안정적으로 잘 됩니다. 그런데 RAID에서는 이게 안 먹힙니다. RAID5는 그렇다쳐도 RAID0과 RAID1은 TRIM지원하는게 안 어려워 보이는데 또 다른 어려움이 있나보죠.
  • lefoot 2010/01/09 12:28 # 답글

    최근 SSD의 성능 벤치마크에 대해서도 논의가 많이 생기고 있습니다. 대표적인 것이, 'pre-conditioning'을 어떻게 하느냐에 따라서 시간대별로, 제품별로 성능의 차이가 크게 변한다는 것이 문제인데요, 따라서 무엇을 SSD의 성능으로 정의해야 공정한 것인가, SSD를 위한 벤치마크를 어떻게 만들어야 할 것인가에 대해 연구도 시작되는 것 같습니다. 현재 대부분의 벤치마크는 단순히 random/sequential page를 read/write 반복하는 microbenchmark가 거의 대부분입니다. 이 경우, SSD와 Disk 의 차이를 극명하게 보여줄 수 있으니, SSD의 장점을 확실히 홍보할 수 있으나, user application에서도 그만한 이득을 볼 수 있는가는 또 다른 문제입니다. 가령 위에 언급된 것처럼, Disk를 썼을때 검색어 검색 시간이 5초이상(혹은 그정도?)이 걸렸으나 SSD를 쓰니 2~3초가 되었는데, 둘간의 random read 속도차이가 50배가 넘는 점을 보면, 둘의 차이가 더 커야 하거든요. 이건 windows 7의 인덱스 파일과, buffer management 기법으로, "디바이스 성능과 Application의 성능"이 decoupled 되어서라고 볼 수 있을 것 같습니다. 짧게 말하면, 잘 디자인 된 macro-benchmark를 이용해서, 디바이스를 바꿈으로 해서 user application이 어느 정도의 이득을 기대할 수 있는가를 평가할 수 있으면 좋겠다 라는 것이, SSD 벤치마크 디자인에 대한 핵심 생각인것 같습니다. 저도 조만간 SSD 하나 질러야 하지 않을까 생각하고 있습니다 ^^;;
  • object 2010/01/09 12:35 #

    그렇죠. 언급하신 문제는 일종의 암달의 법칙이겠죠. 실제 응용 프로그램에서 랜덤 억세스가 차지하는 비율에 따라 천차만별이겠지요. 그런데 말씀대로 SSD에 특화된 벤치 마크를 디자인 할 필요는 있습니다. 저기 스크린샷에 있는 것은 요즘 많이들 쓰는 Crystal Disk Bench인데 최근 SSD 쪽에 더 맞게 QD(Queue Depth=32) 짜리를 넣었습니다. 실제 소스 코드를 보니까 비동기적으로 32개 큐잉해서 보내더군요. 그런데 실제 이 기준이 SSD 수명 측정할 때도 쓰이나 봅니다. 인텔 IDF 2009 자료 중 SSD 관련된 것을 보니 4K 랜덤 쓰기 하중의 기준 중에 QD=32를 넣더군요. 버퍼 없이 바로 쓰는 건 닭짓이니까 최대한 write-back 캐시를 많이 하라는 소리겠지요. PCM은 쓰기가 SSD보다 더욱 나쁘니 요즘 쓰기 성능 개선을 위한 아이디어가 많은데 플래시쪽에도 적용이 가능한지 모르겠군요.

    아.. 그리고 아까 디스크 검색은.. 5초 이상으로 적었는데 실제로는 훨씬 더 걸립니다. 특히 인덱싱이 전혀 없는 상태에서 무대뽀로 검색하면 정말 50배 100배 이상 나옵니다. 간단하게 grep 한번 돌려보면 차이 엄청 납니다. 그리고 정말 어플리케이션 뜰 때 콜드미스는 거의 없다고 할 정도입니다. 포토샵 맨 첨 띄우나 바로 다시 띄우나 차이가 1초도 안 납니다.
  • lefoot 2010/01/09 12:40 # 답글

    답글이 많아졌는데 재밌는 이슈가 있어서 한가지만 더 쓰자면(^^;), 디스크 조각 모음을 SSD는 "할 필요"가 없다라기 보다는, "할 수"가 없다고 보는 편이 맞을 것 같습니다. 위 벤치마크에서 보듯이 SSD에서도 sequential/random read 속도가 분명히 차이가 있습니다(266 vs. 23). 즉 file들이 여러 주소로 fragmented 되어 있는 것보다는, 연속된 영역에 붙어있는 편이 성능을 더 높여줄수가 있다는 것인데, 불행하게도 OS가 SSD내의 Flash Translation Table(FTL)이 관리하는 Logical-To-Physical Mapping Table을 고칠 수 있는 인터페이스가 없습니다. OS는 SSD를 read/write 로만 접근할 수 있을 뿐, 펌웨어 내의 정보를 고칠 수는 없기 때문입니다. 이를 "narrow interface" 혹은 "semantic gap"이라고 해서 Disk 연구하는 사람들은, 이러한 블럭 디바이스들의 인터페이스를 확장해야 한다는 주장을 예전부터 해왔습니다. 조각모음 프로그램이, "fragmented file"이 소유하는 블럭들을, 연속된 공간으로 배치하겠다는 의도로 제작된 점을 비추어보면, 조만간 누군가가, SSD에 새로운 커맨드를 추가해서, 새로운 조각 모음 프로그램을 만들어보려는 시도를 하지 않을까 조심스럽게 예측해 봅니다. SSD에 TRIM 커맨드가 재빠르게 도입된 걸 보면, 왠지 기대가 됩니다 ^^
  • object 2010/01/09 12:48 #

    그렇군요! 할 수 없다가 더 정확하네요. 그나저나 저도 왜 순차/랜덤 읽기가 차이를 보이는가 궁금했는데 좀 더 부연 설명 해주실 수 있나요? 아무리 FTL이 랜덤스럽게 매핑을 한다하더라도 이 차이를 보면 분명 spatial locality가 강하게 있다는데 이게 SSD의 물리적인 특성 혹은 FTL과도 관련이 있나요? 순전히 OS단의 차이로는 그렇게 큰 차이가 날 것 같지가 않아서요.
  • lefoot 2010/01/09 12:59 # 답글

    저도 그 부분이 좀 궁금합니다. Disk는 기계적인 움직임이 있어서 설명이 잘 되는데 말이지요; SSD는 최근에야 좀 보고 있습니다만, 개인적으로 추측해보면, SSD내에 Flash Chip이 하나가 아니라 여러개를 가지고 있는 경우가 대부분이라고 합니다. FTL이, spatial locality가 높은 request들을 이 여러 Chip들에 분배해서 write 해두었다가, Read 할때 parallel하게 읽어와서 sequential access가 좀더 빠를 것 같기도 하고요(마치 RAID의 I/O striping처럼...). 저도 OS단의 차이라기 보다는 "SSD의 물리적인 특성 혹은 FTL"에 그 답이 있지 않을까 싶습니다. 이 부분은 더 잘 아시는 분들께 패스를 ^^;
  • object 2010/01/09 13:19 #

    아.. 답을 알았습니다. 네, RAID0 같은 원리입니다. 플래시 SSD는 당연히 여러 칩이 있습니다. 뱅킹/랭킹 같은 것인데요. 그래야 대역폭이 높아집니다. 동시에 여러 칩에 데이터를 읽고 쓰는 것이죠. 아마 순차 파일은 당연히 여러 뱅크에 고루 분포되어있을 것이고, 그래서 대역폭이 많이 나오는 것이겠네요.

    그렇다면 SSD에서 조각난 파일의 정의는 물리적으로 연속인데 같은 물리 칩에 집중되어있어 뱅크 컨플릭트가 많이 나는 것으로 말할 수 있겠고, 별 효과는 모르겠지만, 조각 모음 같은게 나올 수도 있겠군요. 참고로 대역폭 늘리기위해 여러 뱅크를 두는 것은 캐시, DRAM에서 적용되는 것입니다. 여기서도 뱅크 컨플릭트가 일어나면 대역폭을 깍아 먹습니다. GPU 같이 메모리 대역폭이 매우 중요한 곳에서는 뱅크 컨플릭트도 꽤나 중요한 문제가 됩니다.
  • dhunter 2010/01/09 13:17 # 삭제 답글

    1번은 대단히 편리하지요. 저것 하나만으로도 와이드/멀티 모니터 사용자는 비스타를 건너뛰고 7으로 갈 동기가 충분하다고 생각합니다.
  • object 2010/01/09 13:22 #

    킬러 기능이라니깐요 ㅎㅎ 노트북에는 아직 비스타 깔려있는데 무심코 창을 끌어다 양 옆으로 던진다는..
  •  sG  2010/01/09 14:32 # 답글

    승리의 TRIM!!!
    아 그런데 5년이란 수치는 어떻게 계산하신 건가요? 인텔 얘기 들어보면 이건 뭐 수명에 대해서는 하여튼 걱정할 필요 없다고 열심히 주장하던데... 5년이라면 굉장히 리얼한 수치라 오히려 움찔하게 되네요.
  • object 2010/01/09 15:10 #

    5년이라는 수치는.. 흠.. 근거는 잘 없고요;; 일반 유저가 5년 이상 하드를 잘 안써서 그 정도는 MLC로도 충분할것 같다는 소리입니다.

    http://nvsl.ucsd.edu/papers/Micro2009FTest.pdf
    http://nvsl.ucsd.edu/slides/FTest-FMS-2009.pdf

    여기에 최신 SSD 연구 결과가 있는데, 논문의 3.5 부분을 보시면 재밌는 내용이 있습니다. 특히 그림 6, 7을 보면 SLC의 에러율이 MLC에 비해 매우 낮다는 것을 알 수 있고, MLC는 5000번 이상 지우면 에러율이 슬금슬금 늘어나다가 1만번 넘으면 급격히 늘어납니다.

    이 계산이 맞는지는 모르겠지만, 5천 번 지울 수 있다는 소리는 80GB * 5000 만큼의 데이터를 쓸 수 있다는 소리랑 비슷할 것 같습니다. 그러면 하루에 20GB 어치를 써도 27년이라는 숫자가 단순히 나오기는 합니다.

    인텔 IDF 2009 자료를 보면 SLC + RAID5로 구성한 시스템이 최악의 상황을 가정하도 10~30년 정도의 수명을 보인다고 합니다. 생각해보니 5년은 너무 짧게 제가 가정했네요. 그런데 저렴한 MLC는 1,000번만 지워도 맛탱이가 가니까 빡세게 쓰면 5년 만에도 맛 갈 수 있을 듯 합니다.
  • lefoot 2010/01/09 17:35 #

    필드에서 사용중인 SSD 스토리지 시스템에서 모은 로그등을 바탕으로 수명을 추정한 예는 아직 없는 것 같습니다. 디스크 십만개로부터 로그를 모아 분석한 논문 'Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?' 처럼 large-scale SSD storage system 논문도 수년내에는 나오지 않을까 싶네요. 사실 디스크 벤더들이 디스크 MTTF가 100만시간(=114년)이라고 주장합니다만(그럼 수명은 그거보다 길다는 것인지;), 5년 넘게 쓰는 사람은 잘 없는걸 보면, 벤더들의 말을 그대로 받아들이기는 어려울 것 같습니다만, 아무래도 기계적인 동작이 없는만큼 SSD가 디스크보다는 나은 수명을 보일 것 같기는 합니다. SSD의 경우는 Ram이나 Disk와 달리, In-Place update가 안되기 때문에 Write Amplification 이라는 현상이 발생하게 됩니다. 원래 쓰려던 Data Size보다 더 큰 Data를 쓰게 되는 경우가 발생한다는 것이지요. Garbage Collection만 하더라도, 원래 쓰려던 Data Size에다 Relocation size까지 있으니... 또한, 꼭 user application이 요청하지 않더라도 OS는 데이터들을 주기적으로 Flush하도록 되어 있습니다. ZFS같은 경우는 page의dirtiness에 상관없이 깨끗한 page도 flush 한다고 알려져 있고요. 일반 사용자들의 경우 하루동안 컴터를 사용하면 대략 2GB 의 (OS에 의한) Write Request가 발생한다 하더군요. 이것 말고도, Runtime memory usage가 늘어나게 되면, 필연적으로 swap이 발생하게 되는데, 여기에서도 write request가 많이 발생하게 될 것 같고요. 일반 사용자들도 멀티미디어 데이터를 다수 읽고 쓰고 하게 되는 경우를 생각해본다면... 계산상의 수명보다는 좀 줄어들지 않을까 싶습니다. NetApp이나 EMC 등 대규모 스토리지 구축해주는 업체들이 얼른 로그를 모아 분석해주면 좋겠습니다. :)
  • 아름드리 2010/01/09 14:37 # 삭제 답글

    Windows 7의 1번 기능도 좋지만 WinSplit 유틸리티를 사용하는걸 더 추천합니다.
    Windows 7의 기능을 포함하면서 더 많은 옵션을 사용자가 설정할 수 있구요.
    XP에서도 잘 돌아가구요.
  • dhunter 2010/01/09 15:44 # 삭제

    그거 써봤는데 매끈한 감도 모자라고 해서... 비스타에서 WinSplit 쓰다가 7으로 넘어갔습니다.
  • object 2010/01/10 05:33 #

    저도 dhunter님과 같은 의견입니다. 예전에 그 녀석을 써보기는 했습니다만.. 참 미묘하죠. 기능이 더 풍부해도 착 달라 붙는 맛이 없어 쓰기가 어렵더군요.
  • Designer♬ 2010/01/09 23:32 # 답글

    일단 윈도 서치의 경우 IFilter라는 것을 기반으로 하는데, 요게 공개된 것도 많습니다. 한글 파일 IFilter의 경우 상용으로 판매한다는 것이 문제겠지요. 구글 데스크톱 서치의 경우에는 한글 파일의 내용까지 인덱싱을 해주더군요. 아마 연결 프로그램이 있어서 그걸 기반으로 열어서 검색하는 건지 잘은 모르겠지만, 인덱싱은 잘 되더군요..

    덕분에 수많은 한글 문서들 때문에 윈도 서치는 포기하고 구글 데스크톱 서치로 갈아탄지 오랩니다..

    얼른 한글도 파일 구조를 XML기반으로 공개하는 것이 좋을 듯 한데, 현재 한글 2010베타에서 저장한 파일도 보니 자체 파일 형식이더군요...
  • object 2010/01/10 05:27 #

    다시 한번 구글 데스크톱 검색을 깔아봤습니다. 최신버전은 hwp를 인덱싱 안 하네요. 찾아보니 과거 버전까지만 해줬다고 합니다. 헐.. 사실 저는 아래아 한글 파일이 그리 많은 것이 아니어서 (학부 시절에 썼던 리포트를 검색하고 싶다면 얘기가 달라지겠지만) 큰 문제는 없습니다... 확실히 구글 데스크탑 서치가 성능은 훨씬 좋습니다. 좀 고민해봐야겠군요. 예전에도 구글 데스크탑 검색을 좀 쓰다가 그렇게 윈도우와 잘 연결이 안되는 것 같아 포기했는데.. 몇 일간 써보고 결정해야겠습니다.
  • 분도 2010/01/10 07:55 #

    미지원 - 플러그인 지원 - 자체 지원 - 미지원으로 오락가락하는군요.
  • Designer♬ 2010/01/10 13:05 #

    구글 데스크탑 서치의 경우에도 역시나 추가 플러그인이 필요하다는게 문제입니다 ㅠㅠ
    그리고 윈도랑 뭐랄까 이상하게 궁합이 잘 안맞는 듯 하고, 파일 검색 결과를 굳이 브라우저로 보여준다는 것도 좀 거시기하구요...

    저도 고민이 많습니다 ㄷㄷㄷ
  • object 2010/01/11 11:34 #

    구글을 써봤는데 검색 결과를 빨리 보여주는 것은 정말로 좋군요. 그런데 제가 찾고자 하는 pptx를 못 찾아주더라고요. 희한해서 직접 그 파일을 폴더까지 찾아가서 여니까 그 다음에는 검색이 되네요. 또, 저는 SSD를 주로 쓰고 일반 하드는 20분있으면 꺼지게 했는데 자주 구글 검색이 이 하드를 깨워서 엄청난 레이턴시가;; 어차피 인덱스 파일은 다 SSD에 있는데 좀 아쉽군요. 특정 폴더 아래에서 검색도 가능은 한데, 윈도 탐색기에 붙은 검색 창과 연동이 안 되니 폴더명을 처야하는 불편함도 있고.. 이래저래 일장일단이 뚜렷하군요.
  • Designer♬ 2010/01/12 04:45 #

    아무래도 웹 검색과는 달리 로컬에는 워낙에 다양한 파일들이 존재하니까요...
    그 어떤 검색도구도 모든 파일을 제대로 인덱싱해주지는 못합니다.

    일장일단이 있으므로 자신에게 맞는 검색 도구를 잘 선택하는 것이 좋을것 같습니다.
  • wbkang 2010/01/10 11:21 # 삭제 답글

    이건 완전 잡담인데요... 친구가 예전에 말해줬던건데.. explorer . 말고 start . 써보세요. 3자 적어요!
  • object 2010/01/10 12:21 #

    우와.. 굿입니다!
  • saiparan 2010/01/10 20:15 # 삭제 답글

    SSD에 desktop index 파일이 small random write의 pattern이라면 SSD에는 좋지 않은건 사실입니다.
    TRIM은 wear leveling 과는 관계 없으며 garbage collection을 효율적으로 할 수 있도록 도와줍니다. 수명 및 속도 모두에 긍정적인 영향을 줍니다. TRIM이 없는 상태에서는 한번 다 데이터를 채운 상태에서는 모든 data가 valid 한 데이터로 간주되어 불필요한 관리 오버헤드가 필요로 합니다.
    Flash 수명에는 erase 횟수 (endurance) 외에도 다른 물리적인 제약이 있습니다. 너무 자주 읽어도 오류가 나고 (read disturb), 가만히 냅둬도 시간이 지나면 오류 납니다.(retention period). - see http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf
    제조사가 밝히는 SPEC은 너무 과신하지 않으시는게 좋습니다.
  • object 2010/01/11 11:35 #

    좋은 정보 감사합니다. 저도 스토리지 쪽은 문외한이다가 SSD를 쓰면서 좀 관심을 가졌습니다. Read disturb도몰랐는데 제가 위에 링크 건 MICRO 2009 논문 보고 처음으로 알았습니다. 그래도 워낙 랜덤 읽기/쓰기 속도가 빠르니 좋기는 좋습니다 ㅎㅎ
  • signer 2010/01/10 22:32 # 삭제 답글

    시작->실행-> . 엔터 쳐보세요 ㅎㅎ
  • object 2010/01/11 11:36 #

    유저 폴더가 뜨는군요.
  • yagur 2010/01/12 16:41 # 삭제

    win + r -> . 마우스 없이 =)
  • 이아우 2010/01/11 01:46 # 삭제 답글

    Win7에 여러가지 향상된 UI기능(에어로 쉐이크등..)이 있다는건 알았지만 귀찮아서 챙기진 않았는데, WinKey를 조합한 기능도 꽤 좋은게 많군요 +_+. 그리고 ↕ 화살표일때 세로길이만 최대화 기능은 정말 유용하네요 좋은거 알아갑니다. ;)

    저도 VC++ 6.0를 매우 싫어하는 사람중에 하나인데, VS 2008 Express를 한번 다른팀에게 권유해본적이 있었는데, 깔아보지도 않고 '불편하다, 새로 배우기 귀찮다.' 라는 이유로 사용을 거부하더군요.-_-;
    6.0 버그도 많은데.. 배우려는 자세를 가지지 않는 사람들인거 같아 참 깝깝했습니다.
  • object 2010/01/11 11:36 #

    원래 사람들이 배우기를 귀찮아하죠.. 사실 저도 그렇고..
  • hwang0209 2010/01/12 11:12 # 삭제

    이번에 대학교에 컴공입학인데 vc6 아직도 쓴다네요ㅡㅡ 닷넷프레임워크가 그렇게 무겁고 않조은 건가요?
    2010이 뽐뿌크리이더군요 ㅋㅋ
  • dhunter 2010/01/15 15:20 # 삭제

    교수님들이 귀찮으셔서요 :)
  • 장모군친구 2010/01/12 23:13 # 삭제 답글

    안녕하세요.

    저는 비스타 얼티밋 버전 정품을 구매해서 매우 만족스럽게 사용하던중 윈도7도 정품을 구매해서 설치해서 사용중입니다. 비스타와 크게 달라진 건 없는것 같고 오히려 비스타에서 일부 기능을 많이 빼고 단가를 낮춘 것이 아닌가 싶기도 합니다. 윈도7이 빨라졌다고하는데 그것도 사실 잘 모르겠구요. (비스타도 충분히 빨랐습니다.) 비스타와 윈도7의 차이는 출시전 언론플레이를 얼마나 했냐의 차이가 아닌가 싶어요.

    특히, 윈도7에서 기본 메일 클라이언트가 빠져있는 것에 매우 낙심하고 있습니다. 아웃룩까지 설치할만큼 이메일을 봐야할 필요도 없고 어짜피 라이센스도 없는 저에게 비스타의 기본 이메일 클라이언트는 매우 유용했는데 말이지요.

    이것에 관해서 해결방법이라든가 조언이라든가... 낙심한 저에게 들려주실 코멘트는 없는지요?
  • object 2010/01/13 00:10 #

    라이브 윈도우 메일을 쓰라는 것 같습니다. 그게 꼭 아웃룩 익스프레스 같은 겁니다. 말씀하신대로 그런게 좀 빠져있지요. 그런데 저는 그냥 gmail로 살아가고 있습니다;;
  • rOseria 2010/01/13 01:51 # 삭제 답글

    안녕하세요.

    저는 파일 검색을 할 때 Everything search (http://www.voidtools.com/)를 쓰고 있습니다. 찾는 속도가 매우 빠르고 (거의 실시간), 굉장히 가볍습니다.
  • object 2010/01/13 03:05 #

    감사합니다. 말씀하신 툴은 그런데 파일 내부를 검색하지는 않고 폴더명과 이름만 검색하네요. 그러한 용도로는아주 빨라 보이는군요. 저는 PDF, Doc 파일 내부가지 검색하고자 해서요.
  • dhunter 2010/01/15 15:21 # 삭제 답글

    백신 말인데... 저는 object 님과는 달리 무조건 씁니다.

    최근 겪은 일로 내비게이션을 사서 PC에 꽂았는데 오토런 바이러스가 감염되어있었다거나 -_-);;;

    IE나 Flash의 취약점을 노리는 악성스크립트가 우글우글감염된 커뮤니티라던가를 종종 봐서요...;

    이 부분만은 각자의 취향이니 적당히 하면 될 것 같습니다.
  • object 2010/01/16 16:22 #

    오토런... Windows 7은 그건 좋은 거 같더군요. 오토런이 바로 안 되게 한번 묻습니다. 저도 그래서 일단 AVG인가 공짜 백신 한번 깔아보았는데 이게 무조건 기본적으로 계속 프로세스를 띄우는군요...
  • dhunter 2010/01/19 13:21 # 삭제

    Vista도 최근 보안 패치중 하나에 오토런을 '무조건' 실행하지는 않게 하는 패치가 있었던걸로 기억합니다.
    XP는... 답없죠;
  • 궁금 2010/01/17 05:10 # 삭제 답글

    운영자님에게 크리스탈 벤치를 보면
    QD(Queue Depth=32)

    이런것이 있습니다.. 운영자님이 언급을 하신...
    그런데 이것은 뭔가요? 4k 읽기 새로 정의한것 인가요?

    타사의 저 수치는 기존 4k 읽기랑 별차이가 없습니다..
    인텔만 무식하게 6배 이상씩 차이가 납니다..


    4k 읽기 쓰기
    인텔 SSD는 랜덤 읽기가 무려 35000 iops 나 되는데 4k 읽기를 보면 굉장히 현편이 없었습니다..
    18정도 나오더군요.. 인텔 성능 기준으로 하면 140mb/s 은 나와야 하는데..
    이 QD는 제대로 보여주는 군요..

    물론 4k 쓰기는 엇 비슷하게 보여줍니다..
  • object 2010/01/17 13:17 #

    실제 크리스탈 벤치 소스 코드를 보면 QD=32는 4K 읽기를 바로바로 수행하는 것이 아니라 윈도우 비동기 파일 입출력 함수를 이용하는 것입니다. 즉, 운영체제 차원에서 랜덤 4K 읽기 작업 32개를 모았다가 한번에 보내주는 것입니다. 그 과정에서 최적화가 일어나는 것 같군요. 이건 펌웨어, 드라이버, 윈도우 API 모두 관여되어있을 것같아 저도 잘 모르겠습니다.
  • lefoot 2010/02/04 02:05 #

    Queue Depth=32 라는 것은, 메인보드의 AHCI 에 있는 커맨드 슬롯을 전부 쓰겠다는 의미입니다. 이 경우, Storage Device가 이전 Request를 아직 서비스하지 못했더라도 다음 Request를 보낼 수 있게 되어있습니다. SATA2 디스크의 경우 NCQ라는 기술이, 디스크 커맨드 내의 Request들을 스케줄링해서 throughput을 높이도록 되어있습니다. 말씀하신대로, 인텔이 타사보다 저 수치가 높다면, SSD 내의 스케줄링 알고리즘(아마도 NCQ)에 뭔가 마법을 부린게 아닐까 생각되네요 ^^; 흥미로운 결과 인것 같습니다. (혹시 그 수치 자료를 구할수 있을지...)
  • SY Kim 2010/01/26 03:25 # 답글

    윈도7에 새로운 기능이 많군요.

    메인 PC에 한번 깔아보고는 다시 XP로 엎고, 세컨PC에만 윈도7 쓰고 있는데 뻑하면 "권한이 없습니다" 메시지 때문에 적응이 안되더군요.
  • object 2010/01/26 03:31 #

    저는 그래서 UAC를 끄고 삽니다...
  • in 2017/04/15 14:11 # 삭제 답글

  • in 2017/04/20 02:52 # 삭제 답글

  • for 2017/04/20 06:08 # 삭제 답글

  • generic_cialis 2017/04/21 21:37 # 삭제 답글

댓글 입력 영역