레이드상태의 mtron ssd 의 다시쓰기 캐시가 활성화되어 프리징현상이 일어나는 경우 함부로 이 설정을 끄지 마십시요. 특히 레이드 디바이스의 설정을 수정하는것은 매우 위험한것으로 확인되었습니다. 인텔레이드의 경우 알수없는 오류로 인해 구성설정중 1개의 디스크만이 캐시가 꺼지면서 새로 진입하는데 애로사항이 많이 발생하였습니다 -_-
Do not change the write back cache setting while you are using intel raid. specially setting about raid volume device which that created by intel raid . it will be corruption your disk setting. then you cannot easily repair this.
if some setting is corrupted follow this procedures. i didn't guarantees any data lost, corruption, hardware malfunctions.
사용환경 : Raid : Intel ICH9R raid SSD : Mtron 6035 32GB ssd x 2 Raid type : 0 (stripe)
1. 다른OS로 부팅합니다 (Try to boot another windows )
2. 이 OS에서 레이드로 묶이지 않은것으로 보이는 디스크가 있다면 그 디스크의 캐시를 해제하거나 설정하십시요. 반대로..
(if you can see SINGLE disk devices (which means not belong in raid
volume) reverse setting of write back cache)
3. 다시 부팅을 시도합니다. 만약 보이지 않는다면 다음을 진행해야 하지만, 데이터가 유실될 가능성이 매우 높습니다.
(reboot, if still windows is not working properly do next job. but it
occur data losting)
4. POST 절차에서 나타나는 Intel Matrix Storage controller setting 에서 CTRL+I 를 누르고 진입합니다. 5. 현재 존재하는 볼륨의 정보를 그대로 기억하고 동일하게 삭제하였다가 그대로 만듭니다. (remember currently created volume setting then delete the volume and create again with same size, stripe, volumes. size and stripe and volume name is important to preventing data lost, i cannot guarantees any data losting) 6. 이제 부팅을 시도하면 부팅이 되지 않을것입니다. 왜냐하면 MBR이 날라갔기 때문입니다. 이제 이 MBR을 윈도우즈 시디의 리커버리 기능을 통해 복구하고 부팅해보십시요. 잘될것입니다. (전체복구가 아닙니다. 부트섹터만 자동으로 복구하는 Startup recovery 입니다)
try to reboot! it will be fail. c.o your Master Boot Record is deleted previously you did. now you should recover MBR using windows vista DVD. try to Startup Recovery (not a full recovery). it works.
What????? 그렇다면 순수 윈도우즈 비스타가 사용하는 용량은 20기가라는 이야기가 된다.
도대체 무엇때문에 이 용량을 모두 사용하고 있는가?
그에 대한 설명중에 하나로 다음의 원문을 인용해본다.
WinSxS 디렉터리는 오프라인 서비스도 가능하게 하여, 그 결과 Windows Vista 는 「이미징에 대해서 안전」하게 되었습니다. Windows Vista 이전의 OS 표준에 포함된 기능 배포는 「설치」에 의해서만 제공되었습니다. IT 기술자는 우선 1개의 시스템을 설치하고, 설치 상태를 일반적인 이미지로서 수집하기 위한 타사 제품 도구를 활용하여 복수의 시스템에 배포했었습니다. 즉, Windows 는 「이미지 대응」으로서는 구축되지 않았습니다. 시스템의 80% 이상은 Windows 그 자체로 지원되지 않은 기술을 사용하여 배포 및 사용되어 IT 부문은 Windows 를 효율적으로 관리하기 위해 개별 사양의 솔루션을 생각할 필요가 있었습니다. 또한 WinSxS 디렉터리에 저장된 상태는 오프라인으로 검색할 수 있으므로, 패치를 적용하는데 이미지는 실행될 필요는 없습니다. 이 WinSxS 의 두가지 기능에 의해, Windows Vista 를 배포 하는 IT 부문에 대해서 고 유연성과 비용 삭감을 제공하여, 오프라인에서 표준의 회사용 이미지 생성 및 사용이 간단해 집니다.
오호, 그렇다는것은 예를들어 AMD CPU에 AMD기반 칩셋의 보드에 설치한 윈도우의 경우에도 쉽게 인텔기반의 보드로 마이그레이션을 할 수 있다고 설명하는것 같다.
그렇지만 실제로는 이는 거의 불가능한 마이그레이션 타입이다. 어떻게 이미징에 대해서 안전하다고 말을 하는것인지는 알 수 없는 내용이다. 설치된 시스템을 변경해본 사용자라면 알것이다. 실상업무에서 대다수의 윈도우즈 사용자들이 RIS 로 인한 고통을 겪고 있다. 리눅스처럼 단 3분만에 빠른 전개를 할 수 없기 때문이다.
참고로 지금은 2009년, 흔히 말하는 21세기 과학의 절정을 달리고 있다. 리눅스의 경우 스냅샷을 이용하면 (실제로 회사에서 서버 설치용으로 이용중) 최종 시스템 구성된 SLRCLUB의 표준 시스템이 약 5분만에 구축이 완료된다. 서버를 대량으로 구매해도 서버 10대가 5분만에 동시에 시스템이 레디가 된다는 뜻이다. 윈도우즈는 어떻게 그러한가? 실질적으로 윈도우즈는 일반적인 사무환경에서 원격배포로 시스템을 굴리기가 불가능한것으로 잠정결론이 났다.
Windows XP와 Windows Vista 를 사용하는 사용자와, AMD 플랫폼과 인텔 플랫폼 그리고 알수없는 칩셋의 플랫폼을 쓰는 사용자들이 회사에는 섞여있고 그들의 원하는 플랫폼으로 쉽게 자신들이 쓰던 환경을 이식하는것은 향후 10년내 구현된다면 극찬을 받을 윈도우의 신기술로 보인다.
단지 회사가 원하는 스킬은, 그들의 초기 윈도우라도 시디없이 편리하게 설치하길 원하는것인데 그조차 원활하지 못한게 현실이다.
즉, 내가 쓰던 마지막 시스템 하나를 버튼하나로 쉽게 다른 하드에 설치하고 다른 PC에서 그대로 이용이 가능하다는 것이다. 그러나 윈도우즈는 아직까지도 불가능한 기술로 알려져 있다. 극단적인 기술적인 예겠지만, Pentium 3 로의 다운그레이드 마이그레이션에서는 비스타는 설치가 되지 않기 때문에 이용할 수 없다.
Linux 의 경우 수십억대의 시스템으로부터 중고가 만원짜리 PC까지 내가 쓰던환경 그대로 이전할 수 있지만, 비스타는 재설치부터 시작하여 모든 스트레스를 다 겪어야만 한다.
그러한 상태에 두고 도대체 WINSXS 폴더의 하드링크를 논하는것은 무엇인가?
그리고 정말 하드링크가 정상적으로 동작하는것일까? 그렇다면 그 하드링크의 데이터는 도대체 어디서 발생하는것인가?
실제로, WinSxS 디렉터리의 대부분의 파일은 시스템의 물리적인 파일에의 「하드링크」입니다. 즉, 파일은 실제로는 디렉터리 안에는 존재하지 않습니다. 예를 들어, WinSxS 안에는 advapi32.dll 라는 700 KB 정도의 파일이 있을거라 생각하지만, 실제로는 Windows\System32 내에 있는 파일에의 하드링크가 여기에 표시되고 있습니다. 즉, Windows 탐색기에서 각각의 디렉터리를 보면, 그 파일은 2 회 (혹은 그 이상) 기록됩니다.
상식적인 이야기지만, WINSXS 를 제외한 폴더의 총용량이 10기가다. 그렇다면 리눅스의 심볼릭 링크 (하드링크) 로 예를 들자면, 용량을 차지해서는 안된다. 그렇다면 윈도우즈 전체디렉토리 10기가분이 WINSXS 로 정리되어 리맵되었다 치면 용량이 10기가여야 하는데 왜 20기가를 처잡고 있는것인가? 간단히 계산만 해보아도 견적이 나오는 이야기다. 윈도우즈 디렉토리 속성을 보았을때 20기가라고 찍히면 안되는것이 아닌가?
아무리 하드링크라 하더라도 실제로 디스크 용량이 줄어들었다면 잘못만든것이 아니지않나?
만약 리눅스의 심볼릭 링크를 소프트링크로 보고 스태틱 링크를 하드링크로 본다면 맞게 만든것이다. 그러나 결국 OS가 사용하는 용량이 20기가임에는 변함이 없다. (여분공간을 사용하기 위한 전략적인 방편으로써 하드링크를 사용한 경우)
실제로 SSD에서는 기초적인 소프트웨어만을 설치했을뿐인데 10기가밖에 남지 않았다. 그리고 그 10기가가 남은것은 정말로 10기가가 남은것이다.
윈도우 비스타의 경우 개발툴 및 포토샵등의 프로그램 사용자로 일반적으로 개발,디자인 작업과 관련하여 많은 리소스를 쓰는 사람이라면 이정도 스펙이 필요합니다.
1. 64비트 사용과 8기가 메모리는 필수 8기가를 엇다쓰냐라고 하지만, 그냥 이것저것 작업할때 보면 메모리가 5~6기가이상 차올라가죠.. 포토샵이던 개발툴이던.. 메모리를 많이 쓰는 프로그램들이 있습니다.
2. 최소 레이드0으로 2채널 이상의 하드디스크 레이드 구성 필요 권장사항은 4채널 1+0입니다. 비스타에 프로그램이 여러개 깔린채로 오래쓰다보면 역시 속도저하가 발생하게됩니다. 비스타의 메모리 사용전략으로 인해 고성능 디스크를 가진 사람도 큰 메리트가 없는것으로 보입니다. (파일오퍼레이션을 제외하고) 8채널 1+0 을 사용하고 있는데 4채널 1+0때와 그렇다하게 큰 반응속도 향상을 보진 못했습니다.
3. CPU 는 2.4Ghz 이상으로.. CPU가 느려지게되면 XP와는 틀리게 전체적인 영향이 크게 발생합니다. CPU가 2.0 일때와 2.4 일때등으로 볼때 XP 의 반응속도는 체감적으로 큰차이가 없습니다. 그러나 비스타는 ALT+TAB 서부터 다소 차이가 느껴지며, 전체적인 반응속도에 영향을 줍니다.
4. 안정적인 운영환경을 위해서는 트러블의 점검 필요. 비스타가 다운되는 이유는 잘못된 소프트웨어 와 잘못된 하드웨어 (고장등) 에 있습니다.
대표적으로 잘못된 소프트웨어는 네이트온 메신저입니다. 네이트온 메신저를 사용하지 않는상태에서는 1개월이상의 오랜 러닝타임이 보장됩니다. 네이트온 메신저는 모든 문제의 원흉입니다. 문자메시지 1방에 (문자대화) 모든프로그램이 프리징상태에 빠지게됩니다. 프리징상태의 해결법은 대단히 간단하면서도 귀찮습니다.
1) 네이트온을 킨다면, 메모장이나 로그오프에 대응할 수 있는 프로그램을 띄워놓습니다. 2) 로그오프에 대응할 수 있게 내용을 바꾸시고 저장하지마세요! 3) 네이트온이 프리징이 될 경우 CTRL+ALT+DEL을 눌러 로그오프를 과감히 누릅니다. 4) 메모장에서 저장안했는데 할까요? 라고 물어봅니다.. 취소버튼 누릅니다. 네이트와 일부프로그램만 꺼지고 치명적인 작업손실은 막을 수 있습니다. (메모장을 실행한 위치에 따라 틀립니다)
잘못된 하드웨어는 로그를 남기고 간혹 블루스크린을 동반합니다. 이부분만 해결이 된다면 몇개월이든 리부팅없이 이용할 수 있습니다. 비스타 출시 초기부터 MSDN버전으로 이용을 해오면서 느낀점은 매우 안정적으로 3개월이상 리부팅없이도 잘 사용한적이 있었습니다.
전체적으로 보면;; 비스타라는 OS는 기존시스템에 비해 더 많은 리소스를 먹고있습니다. 몇가지 편의기능을 나누었다 치더라도 손실폭이 크다고 할까요? 일반적으로는 추천하지 않지만, 대용량 프로그램과 연산을 필요로 하는 사용자라면 거의 유일한 선택이 될것입니다. 더 큰 스케일의 컴퓨팅을 지원한다는것, XP 보다 좋아졌다는것은 그정도입니다.
TileList 의 style -_- 로써 imagecell 과 cellrenderer 가 호출되고 있다. cellrender 에 uiLoader 가 함수내 var로 임시 호출되고 있다 따라서 dispatch 되는 이벤트는 개체상속을 받지 못한다.
그렇다 -_- 만약, load 하는 url 에 이미지가 없을 경우, dispatch event 를 통해 error 가 넘어오지 않는다. 이것이 첫번째 문제고, (ioErrorEvent를 설정하면 error suppression 만 가능하지 실제 이벤트가 타고오진 않는다)
두번째 문제는 실질적인 loader에서 뿌리는 error url opening 메시지는 suppression 을 할수없다. 그말은 플래시등의 remote debug 가 활성화된 브라우저에서는 로드를 실패했다는 워닝창이 미친듯이 뜬다는소리다.
그래서 icellrenderer 를 인터페이스 매개체로 cellrenderer 클래스를 상속받은 새로운 imagecell class를 작성하고 내장에 event dispatcher 를 새로작성해주었지만 uiloader 단까지 이벤트핸들링이 안된다. 이말은 클래스 소스를 가져와서 같은형식으로 정의하고 try & catch 로 잡아다 묶어야 한다는소리다. 역시했다 -_-;;
결정적으로 cellrenderer 는 어느파일이 어떻게 안되었는가를 알지못한다. 현재 랜더링하고 있는 파일에 대해 파일명정도밖에는 failed 되었을때 알아오지 못한다. 다른말로는 dataprovider 에 정의된 추가적인 object를 가져와야 하는부분이 있는데, 여기서 dataprovider 랑 renderer가 별도로 노는 사건이 발생하게 되는것이다.
이를 묶어주기 위해서는 콜러보다 더 상위개층 (stage level) 을 통해서 무비클립을 서로 연결해주어야 하는데, 이경우 전체적인 방대한 데이터가 아규먼트로 돌아다니는 문제가 있었다.
그리고 결정타가 있었다. -_- 클릭을 한번하는순간.. 모든 listdata 이미지를 새로 로드한다... 이것도 원형을 가져다 수정할수는 있지만 -_- 갑자기 급 짜증이 나서 때려쳤다.. 한 5시간 낚인기분이 든다 -_-
PC조립은 부품만 맞추어 가져다 끼우는것으로 끝나지만 이외에도 다양한 변수-_-들이 존재한다.
통상적으로 가장 많은 오류현상을 겪거나, 잦은 다운증상을 겪는 경우로 질문하는 경우가 많다.
이 일부의 경우를 대비한 PC 조립 사전 가이드가 필요하다.
FSB, CPU와 메모리 일반PC 정보 일반 PC를 조립하기전에는 FSB에 대한 개념이 필요하다. 현재 가장 많이 사용하고 있는것이 DDR2 PC6400 SDRAM을 여기저기 보편적으로 사용하고 있다. 이녀석은 800Mhz 로 동작한다. 그리고 인텔의 콘로,펜티엄4등은 (E6600등) 1066Mhz 나 800Mhz 로 동작한다. 따라서 메모리 4개를 6400으로 꼽을 경우 배수가 맞게 동작된다. (CPU는 통상 800~1066Mhz의 경우 2~300이 주 코어클락 전압이다 메모리는 듀얼채널을 사용할 경우 2채널이 하나의 버스라인이 되어 버스에 포함되게된다. 복잡하다면 짝수와 홀수 개념으로 보면된다..)
그러나 E6750 이나 (1333Mhz FSB) FSB가 홀수로 끝나는 녀석들은 PC6400 SDRAM (800Mhz) 기준으로 2개를 꼽았을때에 안정적으로 동작한다. 이걸 4개를 꼽게 되면 333(코어전압)*n (e6750의 경우 8) = 2.66Ghz 가 되는데 333 에는 800이 동기화가 되지 않는다. 이 배수에는 800이 나올수가 없기 때문이다. (기본적으로 홀수와 짝수의 multiplier가 될수없다)
그렇게 되면 칩셋에서는 메모리의 클락을 다운싱크를 걸게된다 577Mhz 등으로.. 좋은 메모리는 다운싱크로 동작하여도 별탈이 없이 동작하지만, 일부 제품군의 경우는 전압이 떨어지면 비정상적인 (메모리인터리빙을 시도할때 원활하지않는) 현상이 발생한다. 따라서 시스템이 다운되거나 BSOD 내지는 원인을 알수없는 오동작이 발생하기도 한다.
이때는 메모리의 전압을 0.1V 정도 올리거나 코어전압을 330 정도로 설정하여 (짝수로) 메모리의 듀얼채널 클락이 배수가 맞도록 설정하는 방식으로 일단 메꿀수는 있으나 가급적 1066Mhz 메모리 4개를 꼽는것을 추천한다.
서버용 정보 인텔 MCH3000 급 시스템은 아직 1333Mhz 의 FSB를 지원하고 있지 않다. 따라서 1.3Ghz 급 CPU를 설치할 경우 시스템이 동작하지 않는다. 구매전 CPU와 보드의 정보를 정확히 확인할것. 또한 메모리 동기화의 오류가 있는 모델들이 있으므로 전압조정이 되지 않는 서버보드를 샀다면 메모리 갯수를 늘려 버스를 확보 하는것이 좋다
파워서플라이 일반PC용 정보 파워서플라이는 안정성을 위해 중요한 장치중 한가지다. 이녀석을 잘못사다 끼우거나, 사용환경을 잘못조성할 경우 역시 시스템은 데미지를 입거나 알수없는 오류를 뿜어내기 시작한다. 특히 저가 메모리등은 볼트변화에 민감하고 주 오류의 원인이 이 구동중 볼트변화에 있다. 0.05v 이상의 미세변동이 시작된다면 시스템은 많은 오류를 내기 시작할 수 있다. 가급적 파워서플라이는 5만원 이상의 제품을 구매하는것이 좋으며 (450w기준), 파워서플라이의 유명 브랜드 제품을 구매하는것이 좋다.
그리고 파워코드는 접지형 멀티탭등을 이용하여 아파트나 집의 내벽 콘센트에 삽입하는것이 좋다. 접지형 멀티탭은 잔여전류나 여전등을 케이스에 흐르지 않게 접지로 전송하는 기능이다. 모터가 돌아가는 제품은 모두 접지를 권장하고 있다. PC는 어느이상의 전류가 순간 흐른다면 여파로 여전이 발생하고 이 여전은 접지를 통해 배전되어야 하는데 그렇지 못하고 쌓여있다가 이것이 시스템으로 흘러 직데미지를 입히게 되는 경우가 있기 때문이다. 또한 파워가 감당하지 못하고 역류로 인해 고장이 나는 경우도 상당하다. 무접지 환경에서 동작하던 스튜디오용도의 고출력 고사양 PC들은 잦은 고장이 나고 시스템이 데미지를 입는 경우가 상당했다.
흙을 깊이 50센티이상의 (면적20m3이상의 땅에) 파고 제2규격이상의 접지바 (구리)를 매립해놓고 그위에 물을붓고 이것을 접지컨센트에 연결하면 접지를 시킬수 있다. 그러나 보통 최근의 일반 집이나 아파트는 접지시공이 되어서 나온다.
서버용 정보 파워서플라이는 매우 안정적인 전압을 공급해주어야 한다. 그리고 팬, CPU, 하드디스크등으로 전압을 상당히 많이 소진한다. 설계하는 시스템이 어느정도의 전력을 소비하는지 대충 계산을 해보는것이 좋다. SAS하드,스카시 하드의 경우 38w 를 사용한다 (1개당) cpu는 인텔홈페이지에 소비전압이 써있다. 전압이 모자르게 되면 시스템은 켜지지 않는다. 1개의 팬은 20w~80w 까지 사용한다. 만약 소비전력이 900w 이상일 경우에는 1300w (triple redundant형) 제품을 추천한다. 높은 안정성이 보장된다. (650w 모듈)
그리고 사무실등에서 서버를 운영할때 스토리지급 서버 (고출력요구 서버들)를 접지도 안되는 멀티탭등에 연결하는 경우가 있다. (사무실 자체 벽면에서 접지가 안나오는경우) 이때는 시스템이 크리티컬한 데미지를 입을 수 있다. 서버용 장치는 접지가 기본이며, 이에대한 역필터가 설정되어있지 않는경우가 많다. 따라서 접지가 되지 않는경우 발생하는 모든 데미지가 파워서플라이로 역류한다고 보면 된다. 이 데미지가 쌓이면 파워서플라이가 가장 먼저 고장난다. 따라서 triple 이나 redundant급 이상의 module 제품을 사용하는것이 좋다. 또한 가급적 접지가 되지않는 사무실에서 이러한 장치를 가동시키지 않는것이 좋다.
엠파스는 표준을 어긴 무단 크롤링을 해가고 있다.. 개인정보 노출문제로 중단을 요구했으나 잠깐 뻇다가 뺏던거 도로 다 집어넣는다. -_-
합병된 이후에도 여전히 막장 크롤링은 계속되고 있다. 요 밑에 서버 들어가고 보자 그때도 눈에 띄면 막장 스크램블이 뭔지 보여줄작정이다..
일이 터졌다 이제 얼마나 버틸까? 궁금하다.
하나로는 탈퇴후에도 개인정보를 보유하고,이 정보를 법적으로 5년이던 보유할수는 있다. 그러나 이 자료를 마케팅에 이용해서는 안된다. 그러나 상담원말이 이용해도 된다고 바득바득 우기더라. 이를 마케팅에 이용하는것을 정당화하는 내용의 발언으로 KISA에 요청하여 이를 정정요청을 하였다. 개인정보 막장이다 -_-
이 두회사가 SK로 넘어가려고 하고있다. 이제 10년넘게 써온 011을 해지해야할때가 오는게 아닌가 싶다.
그러나, 집안에서는 FON 을 그다지 사용하지 않았고 netgear ap 를 주로 사용한다.
그러던 어느날 이 공유기를 다른지역에 설치하고 테스트를 하게되었다.
그리고 자주 사용하게 되었고, 이 제품에 문제가 있다는것을 알게되었다.
사이트에서 고객지원을 받으려 글을 써보았지만 글이 써지지 않는다..
이게 1달전 이야기다..
그뒤로 support@fon.co.kr 과 폰 사이트 어딘가에 적혀있던 연락처로 전화를 해보았다.
메일은 회신이 없으며, 전화번호는 자동응답기가 동작했다. 메시지를 남겨주면 연락을 해준단다..
수차 통화해봤지만.. 연결이 안되서 포기하고 있던차에 이런게 날라왔다.
그래.. 고쳤나보다.. 하고 또 열심히 글을 쓴다. 메일주소를 보자 noreply 다. 그러나 어디에도 이 메일은 회신을 하면 안된다는 글이 안써있다 웬만한 자동화 서비스도 좋지만 우리는 전송되는 모든 메일을 관리자가 회송하여 볼수있도록 서비스하고 있다. 서비스의 기본 개념이 부족하다고밖에 볼수없다.
우린 단 한명의 사용자가 회신할수도 있는 사태를 대비해 매일 수천통의 스팸을 걸러내는 시스템을 운영하고 있다. 별에 별짓을 다해야 하는 시점에 넉살좋게 배째라 운영은 모자라지 않는가?
noreply 메일은 가오가 아니다. 전화번호를 사이트내에서 쉽게 찾을 수 없도록 해야한다면, 메일주소 또한 어딘가에 기입하여야 한다.
그러나 fon 사이트에는 서포팅에 관한 이메일을 찾기 힘들다. 이메일 주소 하나를 찾기 위해 둘러보아야 할곳이 너무 많다.