하이닉스는 1TB NVME 처음 선보였을때도 노트북에서 호환 안되는 경우가 많아서 호환성 이슈가 있었습니다....
리테일 시장에 1-2년전 처음 진입해서인지 호환성에 문제가 있었던것입니다.
근데 삼성이 호환성이 안좋다는 이야기는 처음듣네요...
해외 전자 IT 유튜브 대부분 삼성 제품을 1순위로 테스트 합니다... (삼성은 가장 오래된 SSD 1위 업체이죠)
정상적인 소프트업체라면 세계 1위 제품에 호환성을 맞추는게 맞지....
WD/Sandisk 둘이 합쳐도 삼성보다 점유율이 안되는 업체 기준으로 소프트웨어를 만들진 않습니다.
그리고 자체 컨트롤러가 있는건 장점이지... 단점이 아닙니다.
낸드와 컨트롤러를 함께 생산해 호환성과 안정성을 갇출수 있는건 세계에 몇업체 안됩니다.
그리고 자체 컨트롤러와 낸드를 만드는 업체의 SSD 안정성이 , 컨트롤러와 낸드를 따로 조합해 만드는 업체의 안정성보다 훨씬 높습니다
삼성 제품이 WD/Sandisk보다 호환성이 떨어진다는 근거가 있는지 참고 자료가 있는지요?.
리뷰에서 시험해봤자 Windows or Linux정도잔아요 (NVMe NAS만 호환성 시험해서 올려도 특이한 경우고, 컨슈머 라인업을 가상화 서버에 시험해보거나, 커넥터도 안 맞는걸 컨버터 꽃아서 맥같은데 꽃아서 시험해서 올리는경우는 더 없을껍니다)
이런 환경이외를 상정해서 개발도 안 했고, 보장도 안 되고, 실재로 작동 문제 있습니다 (이런것땜에 SATA는 몰라도 NVMe처럼 민감한 타입의 SSD Windows이외를 설치할땐 이런 제조사 제품 추천도 안 하고, 쓰지도 않습니다)
정상적인 회사라면 컨슈머 라인업에 안 맞추고 서버용에 맞추던지 범용으로 시장에 팔리는 컨트롤러를 기준으로 개발하지 컨슈머 라인업의 한줌밖에 안 되는 제품 전용으로 나온 컨트롤러를 기준으로 개발하진 않습니다 (예를 들어 파이슨제 컨트롤러 1가지만 호환되게 개발하면 다양한 제조사의 수십가지 제품이 호환되겠지만, 저런 전용 컨트롤러 호환되게 개발해봤자 1가지 제품 되는데 펌업이나 리비전만 해도 안 될지도 모르는거고, 전용 컨트롤러다보니 구형이랑 신형 제품군 완전히 구조가 달라져서 구형 제품 기준으로 개발한게 신형이랑 완전히 비호환일 수 도 있어서 매번 새로 개발해야할지도 모릅니다)
자체 컨트롤러 장점은 많습니다만 이럴때는 완전히 독입니다
당장에
samsung nvme esxi
라고 구글링해보시면 6.7땐 되었는데 7 올라가면서 안 되었다라던가 심지어는 6.7에서도 안 되었다라던가 이것저것 나옵니다
vmware만 저러는게 아니라 맥에서 돌릴때도 검색해보면 이것저것 나옵니다 (trim 켜면 부트 시간이 오질나게 길어진다라던가 부트조차 불가능하다던가 전원 관리가 안 된다라던가 등등)
참고로 저런거 실재로 시험해서 확인해본적도 있고, 저만 그러는게 아닌지 구글링하면 이것저것 나옵니다
참고로 WD같은경우 SN이라고 붙이기전에 그냥 컬러로만 되어있는 (아마 ~18년인가까지 모델이 저랬을껍니다) 모델조차 아무 문제없이 여러가지 OS에서 잘 붙습니다
그런 잘잘한 이슈는 다른 제품에도 널리 있습니다...
아예 그런 문제가 있으면 해결 책보다... 쓰레기 같은 SSD는 그냥 버리라고 조언 받는 일이 흔하기에 이슈가 덜한것이죠.
오히려 가장 많이 쓰이는 삼성이니까 좀더 이슈가 되기도 한것입니다.
그리고 재밌는 말씀을 하셨는데 애초에 파이슨 컨트롤러 제품은 가상화 서버에 쓸걸 상정하고 만들었나요?
복잡한 서버쪽에 어떤 컨트롤러가 많이 쓰일까요? 파이슨?? 실리콘 모션??? 서버 시장 점유율 살펴보시죠..
가상화 포함 서버시장쪽도 삼성이 압도적으로 클걸요?
[ 그리고 삼성 리테일 제품은 서버쪽에서 쓰이는 컨트롤러를 커스터파이징해서 리테일 제품으로 내놓는다고 알려져 있습니다. 서버에서 검증된걸 오히려 리테일용으로 커스터펌한다는것이죠. 그래서 다른 제품보다 압도적으로 안정성이 높습니다. 더 빠르고 안정성이 요구하는곳에서 충분히 검증하고 내놓으니까 다른곳보다 늦어도 문제가 거의 없는겁니다 ]
애초에 삼성 SSD에 문제가 있었던적이 있었지만 그 시절 경쟁하던 컨트롤러 업체는 아예 망해 없어진게 한두개가 아닙니다.
SSD 역사가 길어서 문제점이 누적된 것이지... 다른 업체는 펌웨어 업데이트 조차 하지못하고 사라지는게 부지기수입니다.
리눅스에서 문제도 삼성 SSD 문제가 아니라 리눅스 드라이버 문제라고해서 삼성이 리눅스 드라이버를 직접 패치해서 올린적도 있죠
그리고 SSD 호환성이란것도 사실 NVME 인터페이스를 어떻게 맞추느냐일뿐입니다.
옛날 MS나 애플처럼 독자 인터페이스를 쓰는것도 아닌데... 삼성 제품은 NVME 표준을 못맞춥니까?
만약 예를들어 OpenGL 표준을 구현한다고 할때 엔비디아나 AMD가 만드는 구현을 쓰고 싶습니까? 아니면 조금만한 몇천억짜리 리눅스 관련 단체가 만드는 OpenGL 구현을 쓰고 싶습니까?
[ 같은 돈이면 무조건 엔비디아 AMD OpenGL 구현을 쓰고 싶듯 , 똑같은 NVME 구현이라면 삼성걸 쓰고 싶은건 매한가지입니다 ]
게다가 오히려 지금 발매하고 있는 SSD들은 NVME 표준을 맞추고 있는데 , 소프트웨어가 오히려 표준을 제대로 사용못하는건 아닌가요?
하이닉스 호환 문제도 사실 하이닉스가 똑바로 구현하고 있는데 서버 소프트웨어가 NVME 표준을 제대로 활용하지 못해서일수도 있습니다.
하이닉스가 쓰레기 제품을 내놓은게 아니라 소프트웨어를 그지같이 짜서 특정 하드웨어에 의존하는 코드를 집어넣은게 문제일 가능성이 큽니다.
그걸 고쳐야하는데 귀찬고 힘드니까 나둔것일수도 있고요.
공짜 버전이라서 신경 안쓰는것일수도 있습니다.. 상용 버전에서 그랬다면 바로 고쳤을겁니다
서버용을 커스터 마이징했다면 드라이버 호환성도 어느정도 유지되어야하는데 저런곳에 물려보면 현실은 다릅니다 (자체 제작 능력 없어서 파이슨꺼 사서 쓰는경우가 오히려 더 잘 붙습니다)
그리고 서버용 라인업은 512b/4k 양쪽 다 되는데, 컨슈머 라인업은 이런 부분 완전히 무시했는지 변경이 불가능하더군요 (하이닉스같은건 자체 컨트롤러라도 양쪽 다 됩니다)
하이닉스 호환성 문제는 발매전 시험이 부족한게 원인이라 추정됩니다 (구형~신형까지 다양한 칩셋과 다양한 제조사 바이오스랑 물려서 시험및 디버그를 해야하는데, 이부분을 게을리 한듯합니다)
물른 잉텔 그래픽처럼 특정 하드웨어 의존일 가능성도 있지만 딱히 떠오르는 구석이 없고 검증해보지 않았으니 패스합니다
물른 둘 다 컨슈머 라인업은 서버용 사용을 상정 안 하고 만들었겠지만, 전용 컨트롤러쪽이 호환성 문제 더 심합니다 (참고로 삼성제 VMWare에서 시험했을떼 VMFS 생성용 Device로 인식되지 않았고, 기컷해야 패스해서 게스트에서 잡는것밖에 사용할 방법이 없었습니다)
OS마다 다른 커널을 쓰다보니 드라이버가 달라서 칩셋 호환성 타고, 자신들이랑 인연이 없는 제조사나 제품군은 상정 안 할 가능성도 있습니다 (특히 애플같은 유닉스는 다 되게 만들 필요가 없습니다) (그나마 WD/Sandisk가 맥이랑 친한건 원래 애플에 SSD 납품하던게 Sandisk였기때문입니다) (특히 맥경우 삼성제 OEM이랑 매우 안 친한걸로 유명합니다 (심지어는 동일 제품의 일반 Retail은 되어도, OEM용 라인업은 아에 부트조차 안 되거나 합니다) )
애초에 저런데 쓰라고 만든 제품이 아니니 안 돌아간다고 딱히 컨트롤러 만든 회사를 비난할 작정은 없습니다 (아마 삼성의 컨슈머 라인업 보증 범위엔 윈도 기컷해야 리눅정도밖에 포함이 안 될껍니다)
다만 현실이 특정 OS랑 호환성 문제가 심하다보니 특정 SSD 제조사를 선호하거나 피하는것만으로 문제 생길 가능성 (랄까 이번경우 아에 작동을 안 하니 선택의 여지가 없음)을 줄일 수 있다면 그게 낫다는것뿐입니다
그리고 삼성제 호환성 문제가 많이 보고되는건 그만큼 시장 점유율이 높다는 반증일 수 도 있습니다
뭔가 주제가 탈선하고 있고, 쓸모없이 길어진것같은데 삼성이나 하이닉스제 컨슈머 라인업 VMWare에서 안 되는건 내장 드라이버랑 호환이 안 되는 문제로 현제 해결책 없습니다
말씀하신 내용을 보면 특정 하드웨어 종속적인 것으로 보이는데요...
그냥 예전에 특정 하드웨어에 종속적인 코드를 짜서 오히려 서버 소프트웨어가 표준 호환성이 없다는 이야기밖에 안됩니다.
즉 비표준 기능을 필요로하는 가상화 서버 소프트웨어라서 문제가 발생한것뿐입니다.
말씀하신 가상화 서버가 요구하는 기능이라기보단 특정 가상화 서버 소프트웨어가 요구하는 사항이라고 해야 맞겠죠.
[ 다른 많은 가상화 서버들이 멀쩡히 삼성제품을 잘 지원해서 돌리고 있습니다. ]
제가 보기엔 해당 가상화 서버 프로그램이 최신 표준 NVME SSD를 지원못하는 낙후된 공짜 버전이라고 밖에 생각안되는겁니다.
표준에서 왜 지원안하는라고하면 그런 의존성이 오히려 문제가 되기때문에 표준에선 지원을 안하는것일수 있습니다.
그리고 표준을 정상적으로 구현했다면 소프트웨어는 표준에 의존한 코드를 짜야지 비표준에 근거한 코드를 짜면 안됩니다.
NVME 표준엔 서버와 리테일용 따로 두지 않습니다. 둘다 해당하는겁니다.
[ 그 인터페이스에는 어떤게 동작해야하는지에 대한 정의다 가 들어 있습니다. ]
애초에 특정 기능이 표준 기능이 아닌데 그걸 토대로 가상화 서버를 구축하는것도 바람직한 소프트웨어라 보기 힘들죠.
이런 특정 기능에 의존한 소프트웨어라면 꾸준히 문제가 될수 있으니 다른 무료 서버 소프트웨어를 쓰는게 좋아보입니다.
그리거 서버와 리테일 컨트롤러의 펌웨어 차이는 NVME '인터페이스'차이가 있는게 아니라 데이타를 처리하는 하드웨어 품질과 알고리즘이 다른것일뿐입니다.
[ 참고로 게임 역시 DX , OpenGL,Vulkan 인터페이스로만 코딩하지 , 그래픽카드가 뭔지에 따라 다르게 코딩하지 않습니다.
만약 그런코드가 있다면 예외 코드로써 앞으로 지원 불가 예정인 Deprecated로 지정합니다. ]
아무리 봐도 내장 NVMe Driver의 호환성 문제입니다 (실재로 삼성이랑 하이닉스 양쪽 다 ESXi에서 시험해본적이 있습니다)
예를 들어 SATA 디스크나 USB같은데 깐다음 저 회사제 컨슈머 SSD 장착후 VMFS 만들러 가보면 안 뜹니다 (PCI쪽에는 목록에 잘 올라와 있음)
해당 증세 과거 NVMe가 OOB가 아니던 구버전에서 Driver 추가 없이 장착하거나하면 발생하는 증세랑 동일합니다 (아니면 업데이트 과정에서 지원 목록에서 제공된 제품을 신버전에 장착했을때도 동일)
이런 디스크를 다른 디스크 없이 장착한 상태에서 설치 시도하면 Driver가 호환이 안 되니 당연히 설치가 안 됩니다
VMWare가 하드웨어 좀 까탈스럽게 차별하는지라 Driver가 모든 하드웨어랑 호환되질 않습니다 (KVM같은거 쓰는 경우는 아무 문제 없이 붙으니 플렛폼을 갈아타면 당연히 문제없이 가상화 서버를 구축할 수 있습니다)
모든 가상화 서버가 VMWare만 쓰는게 아니니 당연히 저런 제품을 써서 가상화 서버 돌리는 경우도 있습니다 (하지만 기업용 서버에 컨슈머 라인업 쓸바엔 중고 엔터 라인업을 쓰는게 신뢰성이 더 높으니 그쪽을 더 선호합니다) (괜히 장터에 5년 넘은 AIC SSD나 SAS HDD같은게 올라오는게 아닙니다)
그리고 프리 버전이랑 엔터 버전 구조상 아무 차이가 없습니다 (심지어는 재설치도 필요없이 키만 등록하면 기능 개방되는 구조입니다)
위에서도 적었지만 저 회사들 제품 펌웨어 작성시 Windows만을 기준으로 삼은듯한 느낌이 있습니다 (Windows에서는 XP조차 문제없이 붙는데도 올해 나온 OS버전이랑 호환이 안 될정도니까요)
그리고 하드웨어 호환성 목록이란게 존재하고, 해당 하드웨어만을 보장하는 이런 플렛폼이나 유닉스처럼 정해진 하드웨어만을 위한 OS라면 표준을 완벽하게 지키던말던 지들 맘입니다 (애초에 이런 하드웨어 쓰라고 만든게 아님)
인터페이스 애기하셨는데 NVMe 프로토콜은 표준 1가지지만 각 제조사별로 전용 드라이버로 구현되는 전용 기능도 존재하고, 서버용 라인업에는 컨슈머 라인업에는 없는 기능이 추가되어 있어서 모니터링이나 관리시 편의성을 제공하거나 합니다 (이거땜에 특정 보드에 꽃으면 아에 부트 안 될 수 도 있습니다) (물른 표준을 제대로 지킨다면 표준 드라이버만으로 작동해야합니다만....제내들은 제대로 안 되니까 표준 안 지키는게 아니냐고 하는겁니다)
게임 애기하셨는데 API를 기준으로 코딩하는데도 특정 겜만 작동 이상한일 아주 허다합니다 (드라이버의 문제라서 드라이버 업데이트 과정에서 해결되기도 하고, 반대로 겜 문제라 패치로 해결되는 경우도 있습니다)
커널처럼 하드웨어 직접 다루는게 아닌데도 호환성 문제 일으키는 판국에 직접 하드웨어를 일일히 다루어야하는 커널이나 드라이버라면 더 높은 확율로 호환성 문제 생기는건 아주 당연한겁니다 (거기다 공식 호환 목록이 아니니 패치 해줄 가능성도 없음)
윈도우만 테스트 했다는 건 좀 근거 없는 이야기신데요
삼성 SSD 리눅스 뿐 아니라 맥 OS에서도 인식됩니다.
FreeBSD 유닉스에서도 삼성 제품 잘만 씁니다.
상용 유닉스에도 아마 잘 돌걸요?
삼성이 SSD 팔면서 윈도우에서만 테스트 해봤을거라는 생각은 너무 안일한 거 아닌가요
리눅스에서 삼성 SSD 이슈가 된걸 억울하다고 , 직접 리눅스 드라이버 버그까지 고친업체인데말이죠.
[ 제가 보기엔 삼성이 WMWare 드라이버 까지 수정할 여유는 없었던거 같아보입니다. 리눅스만큼 큰 커뮤니티는 아니니까요. 오픈소스도 아니겠죠? ]
게다가 (삼성) 리테일 제품은 오히려 개방된 환경에서 쓰이기때문에 온갇 OS에서 다 테스트 해봅니다.
그런데 ....세상에나.... 윈도우에서만 테스트 해봤을거라는 말은 너무 나가신거 아닌가요...
맥은 물론 그 온갇 변종 리눅스, 유닉스에서도 삼성 제품 다 씁니다.
현재 호환성만 보면 삼성 SSD를 인식못하는 OS나 시스템이 있는게 비정상인거죠...
한마디로 VMWare가 드라이버를 제대로 못만드는거에요..
그럼 다른 OS나 시스템에선 왜 인식하나요?
그리고 정상적으로 NVME 표준 인터페이스로 설계했다면 윈도우에서만 인식해도
NVME 드라이버를 가진 다른 OS 역시 문제 없이 인식되어야 하는게 맞습니다.
[ 물론 예외적인 상황이 있기때문에 리테일 제품은 수많은 OS 및 하드웨어에서 테스트 되어 집니다 ]
물론 삼성 제품 버그가 있을수 있습니다만... 상식선에서 VMWare가 그냥 드라이버를 제대로 못만드는거에요.
예로 들었던 DX이야기를 해보자면
DirectX 표준대로 작성하지 않고 비정상적인 방법으로 코드를 짜본적이 있는데요
엔비디아는 그럼에도 불구하고 오류를 내지 않았고 무시하고 넘어간적이 있고
AMD에서는 오류로써 에러를 내었습니다.
AMD가 잘못한것일까요? 엔비디아가 잘못한것일까요?
[엔비디아 덕분에 그 오류를 굉장히 늦은 시간에 알아차리고 그 버그를 고쳤습니다. AMD 드라이버 버그 탓이라고 돌리면서요 ]
오류가 있는 코드로도 프로그램이 이상없이 돌아가게한 엔비디아가 잘한걸로 보이시나요?
틀렸습니다. 오류가 있는건 오류를 발생 시켜야 문제가 없는 코드인겁니다.
될수 있으면 티가 나게 오류가 나야 버그를 잡을수 있거든요.
지금 당장 오류가 안난다고해서 문제가 없는게 아닙니다...
지금 말씀하신 문제 6.7에서는 됐었다하고 7.0에선 안된다하고... 하는 문제에서 쉽게 유추가능한데요
이러는 문제는 기본적으로 프로그램을 잘못짰음에도 몇몇 하드웨어에서는 무시하고 제대로 동작하는것처럼 보이기때문에 문제가 해결되진 않고 있는겁니다.
위 예처럼 AMD가 정상작동했음에도 ...
잘못된 코드가 오히려 정상작동하는 바람에 AMD 드라이버나 하드웨어 탓을 해버리고 마니까요.
VMware ESXi는 Compatibility Guide에 올라와 있는 인증된 하드웨어가 아니면 애초에 정상 동작을 보증하지 않습니다.
표준이 모든 것을 해결해 주면 좋겠지만, 실제로는 동일한 표준에 맞춰 만들어진 장비라도 상호 운용성 테스트를 거치게 됩니다. 표준이 모든 세부사항을 서술하지는 못하며, 같은 표준을 구현하더라도 구현체에 따라서 동작이 달라질 수 있기 때문입니다.
VMware 인증을 받기 위해서는 굉장히 광범위한 테스트를 거쳐야 하며, 시간과 비용도 상당히 들어갑니다. 그리고 이 테스트를 통과한 제품이 호환성 인증 리스트에 올라갑니다. 물론 컨슈머용 디바이스는 그 대상이 아닙니다. 제조사 입장에서 타겟 마켓도 아닌데 굳이 인증을 받아야 할 필요가 없기 때문입니다.
물론 Generic Device 타겟으로 작성된 드라이버이기 때문에 대부분의 장치들은 큰 문제 없이 동작하지만, 그래도 문제가 있는 디바이스는 있을 수 밖에 없습니다. 그리고 그 디바이스들은 지원되는 디바이스가 아니기 때문에 기술 지원도 받지 못하구요.
드라이버를 못 만들어서 그런 것이 아니라, 원래 그런 것입니다.
사족으로 6.7->7.0 미지원 사례는 크게 세 종류가 있습니다.
1. VMKlinux 스택에 의존적인 드라이버를 사용하는 경우
2. 7.0에서 inbox driver 지원이 중단된 경우
3. 업그레이드 할 때 vib를 잘못 설치한 경우
마지막으로 설령 호환되는 NVMe를 쓰시더라도 ESXi자체는 PCH SATA에 설치하시는걸 추천합니다 (업데이트 과정에서 Driver 호환성 변경되는 경우도 있는데, 만일 NVMe에 깔아버리면 부트자체가 안 되지만, 다른 디스크에 깔아두면 부트후 SSH로 붙여서 복구할 수 있습니다) (동일한 이유로 외장 컨트롤러나 칩셋에 붙어있는 디스크도 추천하고 싶지 않습니다)
하이닉스 NVME가 열도 적게 나고 다 좋은데 호환성은 삼성보다 못한 경우가 있습니다..
하이닉스 호환성이 안좋은것 같습니다.
가끔 표준 규격도 엿 바꾸어먹는지 범용 명령(nvme-cli같은것들) 안 먹거나해요
원래 OOB로 안 먹는넘들은 드라이버 필요한데, 정식 지원 대상이 아니니 그런게 없어요
리테일 시장에 1-2년전 처음 진입해서인지 호환성에 문제가 있었던것입니다.
근데 삼성이 호환성이 안좋다는 이야기는 처음듣네요...
해외 전자 IT 유튜브 대부분 삼성 제품을 1순위로 테스트 합니다... (삼성은 가장 오래된 SSD 1위 업체이죠)
정상적인 소프트업체라면 세계 1위 제품에 호환성을 맞추는게 맞지....
WD/Sandisk 둘이 합쳐도 삼성보다 점유율이 안되는 업체 기준으로 소프트웨어를 만들진 않습니다.
그리고 자체 컨트롤러가 있는건 장점이지... 단점이 아닙니다.
낸드와 컨트롤러를 함께 생산해 호환성과 안정성을 갇출수 있는건 세계에 몇업체 안됩니다.
그리고 자체 컨트롤러와 낸드를 만드는 업체의 SSD 안정성이 , 컨트롤러와 낸드를 따로 조합해 만드는 업체의 안정성보다 훨씬 높습니다
삼성 제품이 WD/Sandisk보다 호환성이 떨어진다는 근거가 있는지 참고 자료가 있는지요?.
이런 환경이외를 상정해서 개발도 안 했고, 보장도 안 되고, 실재로 작동 문제 있습니다 (이런것땜에 SATA는 몰라도 NVMe처럼 민감한 타입의 SSD Windows이외를 설치할땐 이런 제조사 제품 추천도 안 하고, 쓰지도 않습니다)
정상적인 회사라면 컨슈머 라인업에 안 맞추고 서버용에 맞추던지 범용으로 시장에 팔리는 컨트롤러를 기준으로 개발하지 컨슈머 라인업의 한줌밖에 안 되는 제품 전용으로 나온 컨트롤러를 기준으로 개발하진 않습니다 (예를 들어 파이슨제 컨트롤러 1가지만 호환되게 개발하면 다양한 제조사의 수십가지 제품이 호환되겠지만, 저런 전용 컨트롤러 호환되게 개발해봤자 1가지 제품 되는데 펌업이나 리비전만 해도 안 될지도 모르는거고, 전용 컨트롤러다보니 구형이랑 신형 제품군 완전히 구조가 달라져서 구형 제품 기준으로 개발한게 신형이랑 완전히 비호환일 수 도 있어서 매번 새로 개발해야할지도 모릅니다)
자체 컨트롤러 장점은 많습니다만 이럴때는 완전히 독입니다
당장에
samsung nvme esxi
라고 구글링해보시면 6.7땐 되었는데 7 올라가면서 안 되었다라던가 심지어는 6.7에서도 안 되었다라던가 이것저것 나옵니다
vmware만 저러는게 아니라 맥에서 돌릴때도 검색해보면 이것저것 나옵니다 (trim 켜면 부트 시간이 오질나게 길어진다라던가 부트조차 불가능하다던가 전원 관리가 안 된다라던가 등등)
참고로 저런거 실재로 시험해서 확인해본적도 있고, 저만 그러는게 아닌지 구글링하면 이것저것 나옵니다
참고로 WD같은경우 SN이라고 붙이기전에 그냥 컬러로만 되어있는 (아마 ~18년인가까지 모델이 저랬을껍니다) 모델조차 아무 문제없이 여러가지 OS에서 잘 붙습니다
삼성경우 예전에는 심지어는 Linux나 BSD쪽에도 문제 심했던적 있었고,
https://www.phoronix.com/news/Samsung-860-870-More-Quirks
https://eu.community.samsung.com/t5/computers-it/bug-or-error-on-870-qvo-ssd-1-tb-cannot-be-detected-on-ubuntu-20/td-p/4253253
최근에도 살짝 시끄러웠습니다
https://bbs.archlinux.org/viewtopic.php?id=232692
좀 희귀한 케이스라던가 시스템 불안정등 이것저것 있습니다 (예전에는 파티션이 박살나서 데이터가 손실될정도로 심각한 문제 있던적도 있습니다)
전용 컨트롤러 잘못 제작하면 장치 잘 안 타서 아직까지 486조차 지원되는 리눅조차 각종 문제에 시달리게 만듭니다
삼성 컨슈머 라인업은 그냥 Windows에서만 시험된 Windows를 위한 제품군이라고 생각해주세요 (거창하게 자료 찾을 필요없이 구글링만 해도 꾸준히 뭔가 문제 있다고 호소하는게 올라올정도로 문제 일으킵니다)
특히 NVMe경우 SATA랑 달리 바로 PCIe에 물리는거라 호환성 문제 생기기 쉽습니다 (하다못해 NIC같은것조차 부트 불능 수준의 심각한 문제 유발할 수 있습니다)
애기가 길어졌지만 VMWare는 컨슈머 라인업을 기준으로 개발하지 않았고, Samsung은 가상화 서버에 쓸껄 상정하고 개발하지 않았습니다
아예 그런 문제가 있으면 해결 책보다... 쓰레기 같은 SSD는 그냥 버리라고 조언 받는 일이 흔하기에 이슈가 덜한것이죠.
오히려 가장 많이 쓰이는 삼성이니까 좀더 이슈가 되기도 한것입니다.
그리고 재밌는 말씀을 하셨는데 애초에 파이슨 컨트롤러 제품은 가상화 서버에 쓸걸 상정하고 만들었나요?
복잡한 서버쪽에 어떤 컨트롤러가 많이 쓰일까요? 파이슨?? 실리콘 모션??? 서버 시장 점유율 살펴보시죠..
가상화 포함 서버시장쪽도 삼성이 압도적으로 클걸요?
[ 그리고 삼성 리테일 제품은 서버쪽에서 쓰이는 컨트롤러를 커스터파이징해서 리테일 제품으로 내놓는다고 알려져 있습니다. 서버에서 검증된걸 오히려 리테일용으로 커스터펌한다는것이죠. 그래서 다른 제품보다 압도적으로 안정성이 높습니다. 더 빠르고 안정성이 요구하는곳에서 충분히 검증하고 내놓으니까 다른곳보다 늦어도 문제가 거의 없는겁니다 ]
애초에 삼성 SSD에 문제가 있었던적이 있었지만 그 시절 경쟁하던 컨트롤러 업체는 아예 망해 없어진게 한두개가 아닙니다.
SSD 역사가 길어서 문제점이 누적된 것이지... 다른 업체는 펌웨어 업데이트 조차 하지못하고 사라지는게 부지기수입니다.
리눅스에서 문제도 삼성 SSD 문제가 아니라 리눅스 드라이버 문제라고해서 삼성이 리눅스 드라이버를 직접 패치해서 올린적도 있죠
그리고 SSD 호환성이란것도 사실 NVME 인터페이스를 어떻게 맞추느냐일뿐입니다.
옛날 MS나 애플처럼 독자 인터페이스를 쓰는것도 아닌데... 삼성 제품은 NVME 표준을 못맞춥니까?
만약 예를들어 OpenGL 표준을 구현한다고 할때 엔비디아나 AMD가 만드는 구현을 쓰고 싶습니까? 아니면 조금만한 몇천억짜리 리눅스 관련 단체가 만드는 OpenGL 구현을 쓰고 싶습니까?
[ 같은 돈이면 무조건 엔비디아 AMD OpenGL 구현을 쓰고 싶듯 , 똑같은 NVME 구현이라면 삼성걸 쓰고 싶은건 매한가지입니다 ]
게다가 오히려 지금 발매하고 있는 SSD들은 NVME 표준을 맞추고 있는데 , 소프트웨어가 오히려 표준을 제대로 사용못하는건 아닌가요?
하이닉스 호환 문제도 사실 하이닉스가 똑바로 구현하고 있는데 서버 소프트웨어가 NVME 표준을 제대로 활용하지 못해서일수도 있습니다.
하이닉스가 쓰레기 제품을 내놓은게 아니라 소프트웨어를 그지같이 짜서 특정 하드웨어에 의존하는 코드를 집어넣은게 문제일 가능성이 큽니다.
그걸 고쳐야하는데 귀찬고 힘드니까 나둔것일수도 있고요.
공짜 버전이라서 신경 안쓰는것일수도 있습니다.. 상용 버전에서 그랬다면 바로 고쳤을겁니다
다시 말하지만 시중에 팔리는 파이슨 , 실리콘 모션 리테일 제품도 가상화 서버에 쓸걸 상정하고 개발하지 않은건 매한가지입니다.
그리고 가상화 서버에 쓰던말던, 윈도우 또는 리눅스, 맥, 안드로이드에서 쓰이든
NVME 인터페이스 표준을 지킨다면 문제가 없어야하는게 정상적인 소프트웨어입니다.
NVME 표준을 지키는데 인식을 못한다? 그러면 100% 소프트웨어 책임입니다. 유지보수 기간이 끝난 깡통 소프트웨어가 아니라면 말이죠.
원래 잘되지만 그냥 최신 하드웨어니까 지원 목록에서 빼놓고 있었을수도 있습니다.
따라서 그 책임을 자체 컨트롤러 만드는 회사에게 돌리는건 정상적인 비난이 아니라 보입니다
서버용을 커스터 마이징했다면 드라이버 호환성도 어느정도 유지되어야하는데 저런곳에 물려보면 현실은 다릅니다 (자체 제작 능력 없어서 파이슨꺼 사서 쓰는경우가 오히려 더 잘 붙습니다)
그리고 서버용 라인업은 512b/4k 양쪽 다 되는데, 컨슈머 라인업은 이런 부분 완전히 무시했는지 변경이 불가능하더군요 (하이닉스같은건 자체 컨트롤러라도 양쪽 다 됩니다)
하이닉스 호환성 문제는 발매전 시험이 부족한게 원인이라 추정됩니다 (구형~신형까지 다양한 칩셋과 다양한 제조사 바이오스랑 물려서 시험및 디버그를 해야하는데, 이부분을 게을리 한듯합니다)
물른 잉텔 그래픽처럼 특정 하드웨어 의존일 가능성도 있지만 딱히 떠오르는 구석이 없고 검증해보지 않았으니 패스합니다
물른 둘 다 컨슈머 라인업은 서버용 사용을 상정 안 하고 만들었겠지만, 전용 컨트롤러쪽이 호환성 문제 더 심합니다 (참고로 삼성제 VMWare에서 시험했을떼 VMFS 생성용 Device로 인식되지 않았고, 기컷해야 패스해서 게스트에서 잡는것밖에 사용할 방법이 없었습니다)
OS마다 다른 커널을 쓰다보니 드라이버가 달라서 칩셋 호환성 타고, 자신들이랑 인연이 없는 제조사나 제품군은 상정 안 할 가능성도 있습니다 (특히 애플같은 유닉스는 다 되게 만들 필요가 없습니다) (그나마 WD/Sandisk가 맥이랑 친한건 원래 애플에 SSD 납품하던게 Sandisk였기때문입니다) (특히 맥경우 삼성제 OEM이랑 매우 안 친한걸로 유명합니다 (심지어는 동일 제품의 일반 Retail은 되어도, OEM용 라인업은 아에 부트조차 안 되거나 합니다) )
애초에 저런데 쓰라고 만든 제품이 아니니 안 돌아간다고 딱히 컨트롤러 만든 회사를 비난할 작정은 없습니다 (아마 삼성의 컨슈머 라인업 보증 범위엔 윈도 기컷해야 리눅정도밖에 포함이 안 될껍니다)
다만 현실이 특정 OS랑 호환성 문제가 심하다보니 특정 SSD 제조사를 선호하거나 피하는것만으로 문제 생길 가능성 (랄까 이번경우 아에 작동을 안 하니 선택의 여지가 없음)을 줄일 수 있다면 그게 낫다는것뿐입니다
그리고 삼성제 호환성 문제가 많이 보고되는건 그만큼 시장 점유율이 높다는 반증일 수 도 있습니다
뭔가 주제가 탈선하고 있고, 쓸모없이 길어진것같은데 삼성이나 하이닉스제 컨슈머 라인업 VMWare에서 안 되는건 내장 드라이버랑 호환이 안 되는 문제로 현제 해결책 없습니다
그냥 예전에 특정 하드웨어에 종속적인 코드를 짜서 오히려 서버 소프트웨어가 표준 호환성이 없다는 이야기밖에 안됩니다.
즉 비표준 기능을 필요로하는 가상화 서버 소프트웨어라서 문제가 발생한것뿐입니다.
말씀하신 가상화 서버가 요구하는 기능이라기보단 특정 가상화 서버 소프트웨어가 요구하는 사항이라고 해야 맞겠죠.
[ 다른 많은 가상화 서버들이 멀쩡히 삼성제품을 잘 지원해서 돌리고 있습니다. ]
제가 보기엔 해당 가상화 서버 프로그램이 최신 표준 NVME SSD를 지원못하는 낙후된 공짜 버전이라고 밖에 생각안되는겁니다.
표준에서 왜 지원안하는라고하면 그런 의존성이 오히려 문제가 되기때문에 표준에선 지원을 안하는것일수 있습니다.
그리고 표준을 정상적으로 구현했다면 소프트웨어는 표준에 의존한 코드를 짜야지 비표준에 근거한 코드를 짜면 안됩니다.
NVME 표준엔 서버와 리테일용 따로 두지 않습니다. 둘다 해당하는겁니다.
[ 그 인터페이스에는 어떤게 동작해야하는지에 대한 정의다 가 들어 있습니다. ]
애초에 특정 기능이 표준 기능이 아닌데 그걸 토대로 가상화 서버를 구축하는것도 바람직한 소프트웨어라 보기 힘들죠.
이런 특정 기능에 의존한 소프트웨어라면 꾸준히 문제가 될수 있으니 다른 무료 서버 소프트웨어를 쓰는게 좋아보입니다.
그리거 서버와 리테일 컨트롤러의 펌웨어 차이는 NVME '인터페이스'차이가 있는게 아니라 데이타를 처리하는 하드웨어 품질과 알고리즘이 다른것일뿐입니다.
[ 참고로 게임 역시 DX , OpenGL,Vulkan 인터페이스로만 코딩하지 , 그래픽카드가 뭔지에 따라 다르게 코딩하지 않습니다.
만약 그런코드가 있다면 예외 코드로써 앞으로 지원 불가 예정인 Deprecated로 지정합니다. ]
아무리 봐도 내장 NVMe Driver의 호환성 문제입니다 (실재로 삼성이랑 하이닉스 양쪽 다 ESXi에서 시험해본적이 있습니다)
예를 들어 SATA 디스크나 USB같은데 깐다음 저 회사제 컨슈머 SSD 장착후 VMFS 만들러 가보면 안 뜹니다 (PCI쪽에는 목록에 잘 올라와 있음)
해당 증세 과거 NVMe가 OOB가 아니던 구버전에서 Driver 추가 없이 장착하거나하면 발생하는 증세랑 동일합니다 (아니면 업데이트 과정에서 지원 목록에서 제공된 제품을 신버전에 장착했을때도 동일)
이런 디스크를 다른 디스크 없이 장착한 상태에서 설치 시도하면 Driver가 호환이 안 되니 당연히 설치가 안 됩니다
VMWare가 하드웨어 좀 까탈스럽게 차별하는지라 Driver가 모든 하드웨어랑 호환되질 않습니다 (KVM같은거 쓰는 경우는 아무 문제 없이 붙으니 플렛폼을 갈아타면 당연히 문제없이 가상화 서버를 구축할 수 있습니다)
모든 가상화 서버가 VMWare만 쓰는게 아니니 당연히 저런 제품을 써서 가상화 서버 돌리는 경우도 있습니다 (하지만 기업용 서버에 컨슈머 라인업 쓸바엔 중고 엔터 라인업을 쓰는게 신뢰성이 더 높으니 그쪽을 더 선호합니다) (괜히 장터에 5년 넘은 AIC SSD나 SAS HDD같은게 올라오는게 아닙니다)
그리고 프리 버전이랑 엔터 버전 구조상 아무 차이가 없습니다 (심지어는 재설치도 필요없이 키만 등록하면 기능 개방되는 구조입니다)
위에서도 적었지만 저 회사들 제품 펌웨어 작성시 Windows만을 기준으로 삼은듯한 느낌이 있습니다 (Windows에서는 XP조차 문제없이 붙는데도 올해 나온 OS버전이랑 호환이 안 될정도니까요)
그리고 하드웨어 호환성 목록이란게 존재하고, 해당 하드웨어만을 보장하는 이런 플렛폼이나 유닉스처럼 정해진 하드웨어만을 위한 OS라면 표준을 완벽하게 지키던말던 지들 맘입니다 (애초에 이런 하드웨어 쓰라고 만든게 아님)
인터페이스 애기하셨는데 NVMe 프로토콜은 표준 1가지지만 각 제조사별로 전용 드라이버로 구현되는 전용 기능도 존재하고, 서버용 라인업에는 컨슈머 라인업에는 없는 기능이 추가되어 있어서 모니터링이나 관리시 편의성을 제공하거나 합니다 (이거땜에 특정 보드에 꽃으면 아에 부트 안 될 수 도 있습니다) (물른 표준을 제대로 지킨다면 표준 드라이버만으로 작동해야합니다만....제내들은 제대로 안 되니까 표준 안 지키는게 아니냐고 하는겁니다)
게임 애기하셨는데 API를 기준으로 코딩하는데도 특정 겜만 작동 이상한일 아주 허다합니다 (드라이버의 문제라서 드라이버 업데이트 과정에서 해결되기도 하고, 반대로 겜 문제라 패치로 해결되는 경우도 있습니다)
커널처럼 하드웨어 직접 다루는게 아닌데도 호환성 문제 일으키는 판국에 직접 하드웨어를 일일히 다루어야하는 커널이나 드라이버라면 더 높은 확율로 호환성 문제 생기는건 아주 당연한겁니다 (거기다 공식 호환 목록이 아니니 패치 해줄 가능성도 없음)
삼성 SSD 리눅스 뿐 아니라 맥 OS에서도 인식됩니다.
FreeBSD 유닉스에서도 삼성 제품 잘만 씁니다.
상용 유닉스에도 아마 잘 돌걸요?
삼성이 SSD 팔면서 윈도우에서만 테스트 해봤을거라는 생각은 너무 안일한 거 아닌가요
리눅스에서 삼성 SSD 이슈가 된걸 억울하다고 , 직접 리눅스 드라이버 버그까지 고친업체인데말이죠.
[ 제가 보기엔 삼성이 WMWare 드라이버 까지 수정할 여유는 없었던거 같아보입니다. 리눅스만큼 큰 커뮤니티는 아니니까요. 오픈소스도 아니겠죠? ]
게다가 (삼성) 리테일 제품은 오히려 개방된 환경에서 쓰이기때문에 온갇 OS에서 다 테스트 해봅니다.
그런데 ....세상에나.... 윈도우에서만 테스트 해봤을거라는 말은 너무 나가신거 아닌가요...
맥은 물론 그 온갇 변종 리눅스, 유닉스에서도 삼성 제품 다 씁니다.
현재 호환성만 보면 삼성 SSD를 인식못하는 OS나 시스템이 있는게 비정상인거죠...
한마디로 VMWare가 드라이버를 제대로 못만드는거에요..
그럼 다른 OS나 시스템에선 왜 인식하나요?
그리고 정상적으로 NVME 표준 인터페이스로 설계했다면 윈도우에서만 인식해도
NVME 드라이버를 가진 다른 OS 역시 문제 없이 인식되어야 하는게 맞습니다.
[ 물론 예외적인 상황이 있기때문에 리테일 제품은 수많은 OS 및 하드웨어에서 테스트 되어 집니다 ]
물론 삼성 제품 버그가 있을수 있습니다만... 상식선에서 VMWare가 그냥 드라이버를 제대로 못만드는거에요.
예로 들었던 DX이야기를 해보자면
DirectX 표준대로 작성하지 않고 비정상적인 방법으로 코드를 짜본적이 있는데요
엔비디아는 그럼에도 불구하고 오류를 내지 않았고 무시하고 넘어간적이 있고
AMD에서는 오류로써 에러를 내었습니다.
AMD가 잘못한것일까요? 엔비디아가 잘못한것일까요?
[엔비디아 덕분에 그 오류를 굉장히 늦은 시간에 알아차리고 그 버그를 고쳤습니다. AMD 드라이버 버그 탓이라고 돌리면서요 ]
오류가 있는 코드로도 프로그램이 이상없이 돌아가게한 엔비디아가 잘한걸로 보이시나요?
틀렸습니다. 오류가 있는건 오류를 발생 시켜야 문제가 없는 코드인겁니다.
될수 있으면 티가 나게 오류가 나야 버그를 잡을수 있거든요.
지금 당장 오류가 안난다고해서 문제가 없는게 아닙니다...
지금 말씀하신 문제 6.7에서는 됐었다하고 7.0에선 안된다하고... 하는 문제에서 쉽게 유추가능한데요
이러는 문제는 기본적으로 프로그램을 잘못짰음에도 몇몇 하드웨어에서는 무시하고 제대로 동작하는것처럼 보이기때문에 문제가 해결되진 않고 있는겁니다.
위 예처럼 AMD가 정상작동했음에도 ...
잘못된 코드가 오히려 정상작동하는 바람에 AMD 드라이버나 하드웨어 탓을 해버리고 마니까요.
표준이 모든 것을 해결해 주면 좋겠지만, 실제로는 동일한 표준에 맞춰 만들어진 장비라도 상호 운용성 테스트를 거치게 됩니다. 표준이 모든 세부사항을 서술하지는 못하며, 같은 표준을 구현하더라도 구현체에 따라서 동작이 달라질 수 있기 때문입니다.
VMware 인증을 받기 위해서는 굉장히 광범위한 테스트를 거쳐야 하며, 시간과 비용도 상당히 들어갑니다. 그리고 이 테스트를 통과한 제품이 호환성 인증 리스트에 올라갑니다. 물론 컨슈머용 디바이스는 그 대상이 아닙니다. 제조사 입장에서 타겟 마켓도 아닌데 굳이 인증을 받아야 할 필요가 없기 때문입니다.
물론 Generic Device 타겟으로 작성된 드라이버이기 때문에 대부분의 장치들은 큰 문제 없이 동작하지만, 그래도 문제가 있는 디바이스는 있을 수 밖에 없습니다. 그리고 그 디바이스들은 지원되는 디바이스가 아니기 때문에 기술 지원도 받지 못하구요.
드라이버를 못 만들어서 그런 것이 아니라, 원래 그런 것입니다.
사족으로 6.7->7.0 미지원 사례는 크게 세 종류가 있습니다.
1. VMKlinux 스택에 의존적인 드라이버를 사용하는 경우
2. 7.0에서 inbox driver 지원이 중단된 경우
3. 업그레이드 할 때 vib를 잘못 설치한 경우
참고로 이거 커널 아마 리눅스의 커스텀 버전일껍니다 (심지어는 6대까지 리눅스용 드라이버 컴파일해서 올릴 수 도 있었으니까요)
커널은 몰라도 Driver를 VMWare에서 새롭게 개발하는 의미는 없기때문에 결국 리눅스 커널의 드라이버란건데 이게 안 된다는건 결국 리눅스랑 호환성이 완벽하지 않은 제품이란 의미입니다
7 특히 U3 가면서 거의 모든 NVMe Driver가 OOB로 바뀌었습니다 (설치할일이 거의 없어진대신 호환성 유무가 명확해짐)
참고로 버전 업글후 안 되는건 대게의 경우 지원 중단이 원인이라 보면 됩니다
7대에서 보안이나 성능등 각종 이유로 중단된건 알고 있습니다 (개편후 패스스루라던가 나아진점 많음)
드라이버는 커널이 살짝만 달라도 비호환이니 별 수 없다고 봅니다
~6.7은 그나마 드라이버 컴파일해서 추가한다는 선택지가 남아있지만, 7부터는 그런 선택지도 없어졌습니다
마지막으로 설령 호환되는 NVMe를 쓰시더라도 ESXi자체는 PCH SATA에 설치하시는걸 추천합니다 (업데이트 과정에서 Driver 호환성 변경되는 경우도 있는데, 만일 NVMe에 깔아버리면 부트자체가 안 되지만, 다른 디스크에 깔아두면 부트후 SSH로 붙여서 복구할 수 있습니다) (동일한 이유로 외장 컨트롤러나 칩셋에 붙어있는 디스크도 추천하고 싶지 않습니다)
포기해야할것 같습니다.
시게이트 와 샌디스크 NVME 잘 설치되서 ... 하이닉스로 샀는데요... 이건 안되는군요.