SHR이나 RAID나 관계 없이 소프트웨어 레이드의 확장은 백업을 반드시 하기를 권장합니다. SHR이 시놀로지가 극한의 태크놀로지로 새로 설계한게 아니며 기존 RAID를 한번 더 묶어서 다시 RAID를 한번 더 한 즉, 이중 RAID이기 때문에 기존 RAID에서 확장을 할 때 백업을 해야 하는 것이면 SHR도 당연히 백업 해야 합니다. SHR은 백업을 하지 않아도 된다는 것은 심히 잘못된 정보 입니다. 12테라로 8칸을 모두 채우실 상황이라면 확장성도 필요한 상황이 아니라 더더욱 SHR을 구성할 필요가 없습니다. 12테라 3장으로 쓰다가, 나중에 16테라 3장을 넣어 확장한다면 SHR이 맞지만, 동일한 용량이라면 굳이 한번 더 묶어서 성능을 떨어뜨리는 SHR을 쓸 필요가 없습니다. 요약하면, 디스크를 한장씩 추가할 때 마다 RAID/SHR 확장이 일어나며 이 과정에서 데이터가 유실될 확률이 증가하므로 당연히 백업은 필요하다. 질문처럼 12테라 3장을 쓰다가 그 이후에 큰 용량의 디스크를 넣어서 쓰겠다면 SHR이 맞다. 입니다. 그리고 SHR은 디스크 추가할때는 반드시 최고 용량 디스크 보다 같거나 큰걸 넣어야 합니다. 12TB 쓰다가 16TB 넣으셨다면 그 이후에는 16TB나 그것보다 더 큰거 넣으셔야 합니다. 뒤늦게 14TB나, 12TB를 넣으실 수 없습니다.

@@Yurangin 아 명쾌한 답변 너무 감사드립니다. ㅜㅜ

Raid 1 + Raid 1 = RAID 10 .. 정말 빠르고 안정성 높은 구성입니다. DB서버에서 가장 많이 사용하는 구성입니다. (오라클DB, MS-SQL), 용량 손실은 좀 있지만 톨러런스도 2 이상입니다.

마지막줄을 제외하면 모든 질문하신 내용은 6:03 에 있는 내용입니다. 참고 바랍니다. 잘못된 질문 교정) 4+4+4 구성에서 4+4+8 구성으로 변경 하게 되면 SHR이든, RAID5든 8TB 만 사용 가능합니다. 4+8+8 이 되어야 말씀하신 효과가 나옵니다. 말씀하신 시나리오에서 용량이 거의 가득 차서 증설을 하게 될 겁니다. 그렇다면 4+4+4 구성에서 4+8+8 구성으로 간다고 할 때, 이미 8TB의 용량이 거의 꽉 차서 4TB를 추가하기 위해 8TB 2장을 사서 기존 하드를 변경하는 것이죠. 그렇다면 이미 8TB는 다 쓴 상황이고 남은 4TB는 오로지 RAID1의 형태로 사용해야 합니다. 즉 속도가 많이 느리겠죠. kzfaq.info/get/bejne/fLd-fLB1rrXSlIk.html 위 영상을 보시면 RAID1일때와 RAID5일때의 성능 차이가 나옵니다. 당장 나스가 200MB/s의 속도 정도만 쓸 수 있는 네트워크 구성이라면 성능에서 손해 보고 들어갑니다.

지원할 지 모르겠네요.. 고급 레이드 컨트롤러는 지원하고.. 그것이 Raid 50 이지만.. 하드 드라이브 갯수는 자유롭지는 못합니다... 왜냐면.. 돈과 편의성보다.. NAS는 데이터 보호와 유지가 더 중요하기 때문입니다.. Enterprise NAS 가 고민할 내용이요 개인용 시놀로지는 그런 것 까지는 지원할 필요가 없겠죠..

업그레이드가 잘 못 된 겁니다. 시놀로지는 완벽하지도 않고.. 생각보다 오류가 많아요.... 윈도우랑 비슷한 수준... 그래서 엔터프라이즈가 될 수 없고... 개인용으로 남죠.

네.. SHR로 확장 가능합니다 RAID5로는 확장 않되요..

저는 DS920+에 4테라 4개를 SHR = 정상적으로 Raid5 구성하면 전송속도가 최고 450MB/s 나올 수 있습니다. 하지만 1G 망에서는 110MB/s 로 사용하고 게셔서.. 그 차이를 알지 못합니다.

RAID1이 여러군데 들어있으니 읽을때 속도가 빨라야 하는게 이론상 맞으며, 실제로 그래야 하지만, 실제 구현은 국제 표준이나 이론과 다르게 할 때가 있습니다. 실제로 시놀로지에서 RAID1을 구성하신 네트워크를 통해 RAID1 디스크에서 컴퓨터로 복사해 보면 하나의 디스크만 사용률이 올라갑니다. 이는 실제 이론과 구현이 다름을 보여줍니다. 결국 1Gbps로 네트워크를 통해서 가면 똑같겠지만, SMB 멀티채널을 구성하거나 2.5Gbps USB 랜카드를 구성하거나, 10Gbps를 연결해서 쓸 수도 있는 만큼, 단지 질문자의 “단지 1G망으로 연결된 경우라면 둘의 속도는 똑같이 느껴집니다. 고로 SHR을 쓰지 않는 이유로는 납득이 되지 않으네요.” 문장 역시 성능이 매우 중요했던 저에게는 납득 가지 않습니다. (10Gbps의 경우 디스크 6개 이상 모델에서 구성 가능) 모든 사람이 1Gbps 만 쓰지 않습니다. 또한 파일의 복사 뿐 아니라 저같은 경우 시놀로지 나스 내에서 DB가 상단한 양의 데이터(ex, 500만건의 데이터을 순서대로 연산하고 통계취합 하기, 특정 시점의 데이터와 사용량을 토대로 적분해서 소비전력 계산하기 등등)를 아주 빠르게 처리해 줘야 할 필요가 있는데 이러한 데이터가 어떤건 RAID1 영역에, 어떤건 RAID 5 영역에 있다면 I/O에서 심한 병목이 옵니다. 다만 이렇게 성능이 필요한 상황을 이 영상에서 저는 설명하지는 않았습니다. 특수한 영역이니까요. 정리하면, 1. 질문자의 상황이라면 SHR은 좋다 이며, 이는 제가 영상 7:03에 이야기한 케이스와 일치합니다. 2. 유랑인은 나스를 특수하게 사용합니다. 제 영상들이 초보자들을 위해서 만들었다고 해서 초보자 처럼 단순하게 쓰지 않습니다. 이 영상의 제목은 "내가 쓰지 않는 이유"이며 당연히 여러분들에게 적용되지 않을 확률이 높고, 대부분의 케이스가 7:03 케이스라고 생각합니다. 3. SSD 캐시의 경우도 마찬가지로 일반적인 분들에게 추천하지 않지만 저는 사용중입니다. (내가 SSD 캐시를 추천하지 않는 이유 영상에서 나옴) 4. RAID1은 이론상 모든 디스크에서 읽기를 시도해야 하지만 시놀로지는 그렇지 못합니다. 이 영상에서 나왔던 것은 모두 테스트를 거쳤던 내용입니다. 테스트 내용까지 넣고 20분짜리 영상 만들고 싶지 않았고, 그러한 장면을 넣지는 않았습니다. 별도 영상으로 만들어볼까 합니다. 원본 댓글은 다음과 같습니다. ---------- 속도 편차 부분에 대해서 이해가 안되네요.. Raid 1 에 들어있으면 속도가 느리단 뜻인가요? 저장속도는 Raid1 > Raid5 라는건 누구나 아는 사실이고 읽는속도는 Raid1 이 동일파일이 2군데 들어있으니, 읽어들이는 속도도 2배로 빠르지 않나요? 속도를 좌지우지하는건 10G망 정도 되면 Raid1 과 Raid5가 차이가 날수 있겠지만, 단지 1G망으로 연결된 경우라면 둘의 속도는 똑같이 느껴집니다. 고로 SHR을 쓰지 않는 이유로는 납득이 되지 않으네요. 참고로 저는 Raid10을 선호합니다.

RAID1에 대한 실험입니다. 참고 바랍니다. kzfaq.info/get/bejne/fLd-fLB1rrXSlIk.html 영상거리 만들어주셔서 감사합니다.

개인에게는 SHR이 좋은 선택지가 될 수 있습니다. 유연성. 확장성이 더 중요하죠.. 개인에게는 .. 하지만 회사.기업은 안정성이 그냥 제일 중요합니다... 속도도 안 중요해요..

SHR은 항상 스토리지 풀에서 가장 작은 디스크보다 같거나 더 큰 용량의 디스크를 넣어서 변경해야 합니다. 1테라를 10테라로 바꾸면 10 2 4 8 8 구성이 되며, 다음에 2TB 바이트는 2TB와 같거나 큰 녀석을 넣어야 합니다. 따라서 10TB를 넣어도 됩니다. 이런식으로 모든 디스크 용량이 같아지면, 내부적으로는 여러개의 볼륨이 JBOD 된 것이기 때문에 완전한 RAID5와는 조금 다른 구성입니다. RAID5와 유사해지며, 같아지지는 않습니다.

@@Yurangin 성능적인 면에서 유사해져 가는 걸까요?

성능적인 면에서도 RAID5가 더 유리합니다. 얼마나 유리한지는 테스트 해 보지 못해 단언할 수 없으나, 약간 (5% 이내 추정) 유리할 것으로 추정됩니다. 이 추정은 저의 뇌피셜이며 시놀로지 공식 정보가 아님을 밝힙니다.

@@Yurangin 앗! 그런데 10T로 교체한다고 해도 1T 만 복구에 사용되고 나머지 9T는 노는 거 아닌가요? 이미 다른 디스크들은 레이드 구성이 완벽하게 되었있는데... 9T 사용하겠다고 레이드5를 풀고 새로 묶을까요?

없음. 1개는 단일 디스크랑 같고 2개 디스크면 RAID1과 같음

1개의 하드는 다 동일하고 아무 의미가 없어요..

동일용량이라면 사실상 RAID 입니다. SHR-2를 쓰시니까 RAID6죠. 이번에 DSM 7에서 RAID6가 성능이 많이 향상됐다고 하던데 어떤가요? 저는 RAID6을 쓰지 않아서 궁금하네요.

@@Yurangin 아직 DSM7로 안넘어갔어요 ㅎㅎ 지금 백업용으로 쓰고 있는 218은 DSM7이 큰 문제는 없었는데 메인은 아직은 좀 불안해서 못올리겠어요 ㅎㅎ

@@Minrea_Jo 메인나스면 아무리 성능 향상이 있다고 하더라도 내가 쓰는 모든 기능이 문제 없다고 확신될때만 넘어가세요.

제가 알기론 구글포토처럼 백그라운드에서 백업이 됩니다. 혹시 설정을 안하신건 아닌가요?

@@user-bj1yl8hk7b 따로 어떤 설정을 해야합니까?

SHR은 스토리지풀에서 가장 작은 디스크보다 용량이 큰 것을 넣어야 합니다. 즉 16 TB 한장으로 풀을 구셩하셨으므로 앞으로 해당 풀에는 16TB와 같거나 큰 하드를 넣어야 합니다. 아마 지금 모든 데이터를 16TB 외장하드에 백업한 후 4 4 14TB로 SHR을 구성하시고, 백업 데이터를 스토리지 풀에 넣은 후 16TB를 스토리지 풀에 추가 하면 됩니다. 추가 방법은 제가 이미 별도 영상으로 올려둔게 있습니다. 특정 공유 폴더만 백업하는 방법은 하이퍼백업 영상 찾아보시기 바랍니다. 이미 올려둔게 있습니다.

@@Yurangin 자세한 설명감사합니다. 다시 세팅할 생각에 벌써 지치네요..큽 ㅠ

괜찮아요.. RAID 5 구성하면 되죠..

이 경우 용량이 같아 SHR 이던 RAID5 던 동일 합니다. 용량이 다른 하드들일때 SHR 이 중요한데.. 이에 비하여 RAID5 는 무었이 좋냐.. 안정성이 더 좋습니다. 실제로 SHR 써 보시면 가끔 문제를 볼 수 있을 겁니다...RAID 라는 것은 5~10년을 설계합니다. 5년동안 거의 한번도 문제가 없도록 설계하고 만든것이 RAID 5, RAID 6 입니다.. 한 두번의 문제가 퀄리티 입니다. 은행자료. 기업용자료.. 이런게 문제되면 난리나겠죠.

나스는 결국 SATA3 규격을 사용하고 있고, 이 규격의 속도 한계는 6Gbps로 약 500MB/s 입니다. 그런데 이 속도는 하드디스크 4~5장 RAID 하면 얻을 수 있는 속도 입니다. 따라서 단순 속도 측면에서도 SSD로 구성하면 메리트가 없습니다. 더불어서 전세계에서 하드디스크와 SSD를 가장 많이 사용하는 구글이 내놓은 보고서에 따르면, SSD가 하드보다 갑자기 죽는 경우가 많아서 더더욱 백업을 철저하게 해야 한다고 언급하고 있습니다. 속도 보다 IOPS가 필요한 경우라면 SSD로 구성하는게 맞지만, 그 이외의 경우라면 하드디스크가 더 좋아보입니다. 물론 비용을 무제한으로 사용할 수 있다면 SSD로 구성하고 백업 시스템을 더 철저하게 구성해도 되겠죠.

안정성은 떨어지지만 속도는 아주 좋습니다.. 10G 랜카드 추가로 설치 하여 고속 NAS를 구성할 수 있습니다. 영상편집, 영화편집 스튜디오에서는 그렇게 구성합니다. SSD 2TB x 24개 RAID5 구성+10G NIC // SSD 2TB x 24개 RAID5+1 구성+10G NIC

보통 서로 다른 부품을 연결한 경우를 헤테로지니어스 시스템이라고 하고, 동일 부품으로 올인한 경우를 호모지니어스 시스템이라고 합니다. 일반적으로 호모지니어스를 선호합니다. 즉 같은 용량, 같은회사, 같은 모델을 사용하려고 노력합니다만, 단종이 되는경우 어쩔수 없이 상위 제품을 사용하면서 남는 용량을 버리게 됩니다.

엔터프라이즈 환경에서는 SHR을 거의 사용하지 않습니다..... SHR은 개인용입니다. 안정성이 떨어져요..

레이드가 뭔지 모르시네요.... 하드가 죽는다고.. 뻑난다고.. 왜 데이터를 날려야 하나요.... 하드 죽어도 상관없어요.. 그래서 Raid 를 구성하는 것입니다.

결론부터 말씀드리면 SHR은 느리다 입니다. 하지만 계속 SHR을 쓰시라고 말씀 드립니다. 일단 영상에서 나온 현대 파일 시스템의 margin에 대한 설명을 무시하고, 그냥 무조건 디스크의 처음부터 기록을 한다고 합시다. 저같은 경우 NAS 설정하고 바로 세계일주 영상과 사진을 보관했으니 이러한 자료들이 가장 먼저 기록되었으므로 RAID5에 디스크 5장 사용하는 영역에 기록될 것이고, 최근에 작업하고 있는 코드들 같은건 나중에 넣었으니 RAID1의 영역에 저장될 것 입니다. 결국 어떤파일은 느리고, 어떤파일은 빠릅니다. 단지 이 순서가 랜덤인지, 순차인지만 다른거죠. RAID라면 원판(디스크)에 기록하는 하드 특성상 당연히 뒤로 갈 수록 느려지지만, 여전히 모든 파일을 모든 디스크에서 균등하게 나눠서 읽고 처리하게 됩니다. 결국 성능을 중요하게 생각한다면 margin 여부에 관계없이 SHR이 RAID보다 느린게 맞습니다. 하지만 첫문단에 언급하신 것 처럼 장점을 포기 못한다면 사용하는데 전혀 문제가 없습니다. 저도 "SHR이거 완전 똥입니다." 이렇게 이야기 하는게 아니니까요. 영상에는 말씀하신 것 처럼 장점과 단점이 모두 나오며, 저에게는 해당 단점이 치명적이였을 뿐, 다른 사람에게는 치명적이지 않을 수 있기 때문이죠. 여기까지가 저의 1차 답변입니다. 자 그럼 이제 질문자의 두번째 문단을 봅시다. 일단 iSCSI든, CIFS든 의미가 없습니다. 결국 파일은 디스크에 저장하는데, OS에서 사용하는 파일 시스템으로 저장됩니다. CIFS나 iSCSI 같은건 이를 한번 재 포장해서 더 추상화(Abstraction) 해 준것에 불과 합니다. 즉 시스템이 결국 저장할때 쓰는 파일 시스템인 Btrfs, ext4를 사용해 저장됩니다. 따라서 "iSCSI로 사용한다면 모를까요" 는 틀린 말입니다. 파일시스템이 나 다르게 기록할래 하면 iSCSI 이미지가 순서대로 디스크에 저장될 리 없습니다. 즉 질문하신 요점이 Margin에 따라서 시놀로지가 파일을 저장하는게 맞냐? 라고 물어보시고, CIFS, iSCSI를 언급하신건 앞뒤가 안맞습니다. 따라서 이 문단에서 말씀하신 내용은 그냥 넘어가겠습니다. 이제 세번째 문단을 보겠습니다. --- 아래는 원본 댓글 인용입니다. ------- 시놀로지가 저장된 파일의 안전을 위해서 튜닝을 했다고 한다면, 시놀로지의 파일시스템 드라이버가 SHR의 특성에 맞게 4:50 이 예시의 A 영역에 최대한 기록을 한 후에 노란색, 그 이후에 녹색, 푸른색 영역에 기록을 하겠죠. ---- 인용 끝 ------ 이것은 제가 가장 처음에 이야기 했습니다. 이렇게 하더라도, SHR이 느린게 맞습니다. 역으로 제가 궁금한게 있습니다. 저장된 파일의 안전을 위해서는 튜닝을 할 필요가 없습니다. 어차피 SHR은 RAID1과 RAID5로 디스크 고장 한장을 허용하는 상황인데, 기존에 구현된 RAID1과 RAID5만 가져다 쓰는데, 어떤 튜닝을 해야 파일이 더 안전해 지나요? 제가 이부분을 이해하지 못했습니다. 자 그럼, 좀 다른 이야기 해 보죠. 시놀로지는 과연 Margin을 사용해서 기록할까요? 하지 않을까요? SHR은 과연 별도로 다른 방식으로 기록할까요? 하지 않을까요? 말씀하신 것 처럼 공식 문서에는 정확히 나오지는 않지만, 공식문서에는 다른 것들을 설명하면서 나오는 곁가지에서 추론할 수 있는게 있습니다. 먼저 시놀로지 나스의 하드를 모두 떼어내어 리눅스 컴퓨터에 장착한 다음에 리눅스에서 파일을 열어 볼 수 있습니다. RAID를 했던, SHR을 했던 말입니다. kb.synology.com/ko-kr/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC 이걸 설명하면서 사용하는게 mdadm입니다. 실제로 시놀로지는 소프트웨어 레이드를 사용하며, 시놀로지의 모든 레이드 특성은 이걸 따릅니다. SHR은 용량에 맞춰 RAID를 나눠서 하고, 결국 이걸 하나의 LV(논리 볼륨)으로 묶어서 사용하는 것 뿐이죠. 만약 시놀로지가 최적화한 파일 시스템으로 기록한 것이라면, Btrfs가 아니라, ext4가 아니라 다른 파일시스템으로 이름을 붙여서 사용했을 것이고, 다른 리눅스에 붙였을때 마운트도 되지 않고, 파일을 읽지도 못할 것입니다. 하지만 이렇게 마운트해서 파일을 그대로 복구해서 사용할 수 있습니다. 그렇다면 ext4에 적용된 margin 역시 그대로 적용되고 있다고 역으로 추측해 볼 수 있습니다. 자 이제 부터는 저의 뇌피셜과 소프트웨어 개발 경험에 기반한 내용입니다. 저는 시놀로지가 리눅스 커널을 직접 수정하거나, 기존에 나와있는 파일 시스템을 수정했다고 생각하지 않습니다. 파일시스템은 안정성이 최우선이며, 정말 개발하기가 힘든 것 중 하나입니다. 시놀로지 정도 되는 회사는 이런걸 하지 못합니다. 적어도 MS, 애플, 구글 정도는 되어야 합니다. 따라서 기존 리눅스에서 사용했던 걸 그대로 사용하고 있을꺼라 추정합니다. 또한 mdadm이나 LV 관련한 것들이 GPL이라 소스코드를 공개해야 하는데, 시놀로지는 이 부분에 대해서 소스코드를 공개하고 있습니다. sourceforge.net/projects/dsgpl/ 시간상 공개된 코드를 다 볼 수 없어서 mdadm 부분만 열어서 보았는데, 거의 대부분의 내용들이 기존 mdadm 코드와 동일했고 만든이도 Synology가 아니라 Neil Brown이었습니다. 물론 syno 관련 모듈들이 있었는데, 전부 RAID Resync 어떻게 하는지 정의해 둔 것이었고, 별 다른걸 보지는 못했습니다. 그리고 혹시 시놀로지가 만든 드라이버가 있나 싶어 커널 모듈들을 살펴 봤는데 dm_mod가 있었습니다. SSD캐시의 메타데이터 핀잉과 관계 있어 보였고, 오히려 찾다가 시놀로지가 보안관리를 어떻게 하는지의 관련된 모듈만 좀 보다가 말았습니다..... (다른거에 눈이 더 가버린...) 이게 어떻게 보면 가불기인데, 저 역시 경험과 위 근거들을 토대로 시놀로지는 ext4나 btrfs를 수정하거나, 하드디스크의 드라이버를 수정하는 등의 행위를 하지 않거나 못한다고 결론 내렸습니다. (같은 내용을 보고 다르게 해석할 여지가 있을 수 있을겁니다.) 가장 간단한 방법은 SHR을 5개 정도의 디스크를 사용해서 실제로 프로그램을 짜서 시나리오에 맞춰 Read Write 해 보는 것인데 베이에 여유가 없어 이 방법을 제가 시도해 볼 수 없네요. 혹시 가능하다면 한번 해 보시고 알려주시면 좋을 것 같습니다. 저도 궁금하긴 합니다. 마지막으로 정리해 보자면 1. 시놀로지가 ext4를 사용하든, 자체 제작 ext100을 사용하든 관계없이, margin 관계 없이 파일의 배치에 따라 SHR은 속도가 파일마다 다르다. 2. 질문의 논점은 SHR에 대한 내용 같아 보이지만, 요점 정리를 해 보면 파일 시스템 margin 적용 여부에 대한 것이다. 3. mdadm, lv 등으로 추론해 볼 때, 시놀로지는 별도로 파일 시스템을 만들지 않았다(고 추정된다.) 따라서 margin도 그대로 동작할 것이다(고 추정된다.) 4. (뇌피셜) 시놀로지 정도 급의 회사는 파일시스템 못 만든다. (프로그래머의 경험) 더 필요한 내용 있으시면 말씀 주세요. cf) 최근 이상하게 글을 장문으로 쓰면 삭제되거나, 질문자분이 댓글 삭제하시거나 하더라구요. 삭제 대비해서 아래에 원래 질문 댓글을 붙여 넣어 두겠습니다. 나중에 혹시나 삭제될 경우 (구글이 지우는건지..) 제 글만 남아서 다른분들이 이 뻘글은 뭐지? 라고 할 수 있으므로... ---------------------------------------------- 클래식 레이드를 쓴다면 애초 모든 드라이브의 용량이 동일해야 온전하게 이상적인 저장공간을 쓸 수 있는것이고 결과적으로는 모든 드라이브가 확장되기 전엔 용량을 손해봐야 하고 결국 모든 드라이브를 동일한 용량으로 맞추게 될것이므로 클래식 레이드를 사용할 생각이 없습니다. 중간에 설명하신 보편적인 파일시스템에서의 파일 기록 방식을 시놀로지에서 동일하게 따를까요? 이 부분은 '알 수 없다.'라고 생각합니다. iSCSI로 사용한다면 모를까요. CIFS같은 네트워크 파일 시스템에서 파일을 기록한다면 그 파일이 실제 디스크의 어느 위치에 기록될지는 호스트가되는 시놀로지의 파일시스템 드라이버에서 결정하는것이죠. 바로 윗줄에서 처럼 알 수 없는 영역이지만 시놀로지가 저장된 파일의 안전을 위해서 튜닝을 했다고 한다면, 시놀로지의 파일시스템 드라이버가 SHR의 특성에 맞게 4:50 이 예시의 A 영역에 최대한 기록을 한 후에 노란색, 그 이후에 녹색, 푸른색 영역에 기록을 하겠죠. 이 부분은 기술문서에 명시된것도 찾을 수 없어서 일단 저로써는 단정지을 수 없지만 유랑인 님은 영상의 설명과 동일하게 기록한다고 단정지을 수 있을지 궁금합니다. ----------------------------------------------

@@Yurangin 만약 제가 댓글을 삭제한다면 삭제된 글의 댓글이 나타나는지를 모르겠군요. 암튼 댓글 내 링크가 있으면 큰 확률로 스팸처리 되는것같습니다. 덕분에 VMware의 이미지 포맷인 vmdk가 일정 용량으로 분할되어 있을 때 대다수 파일 확장이 이미지의 앞 번호 순서대로 확장되는걸 링크로 걸어드릴수도 없으니 아쉽군요. 저도 제 경험을 기반으로 뇌피셜로 풀자면, 꼭 디스크의 여러 부분에 분산되어 저장되지 않는다고 생각하는 부분으로 파티션 할당용량을 줄일 때 걸리는 시간때문입니다. 앞 문단과 같이 분할된 이미지의 앞 번호를 중점적으로 확장되는것도 있고, 윈도의 NTFS나 리눅스의 btrfs 용량을 백기가 이상, 수백기가 이상 많이 사용한 상태에서 파티션을 분할하기 위해, 또는 재배치를 위해서든 축소할 때 골고루 분할되어있다면 데이터를 앞으로 옮기기위해 그만큼 시간이 걸려야겠죠. 하지만 금방완료됩니다. (지금은 zfs로 이전하여 btrfs를 안쓰고있지만 LVM+btrfs로 머신의 파일시스템을 구측하여 사용할 때 확장 축소 여러번 해보았지만 영상때문에 몇테라씩 사용중이여도 축소 금방되었습니다.) 또한 최근에 100기가 정도밖에 사용하지 않는 가상머신의 디스크가 불필요하게 3테라 단일로 할당되어 파티션을 200기가로 줄이는데 몇분조차 걸리지 않았습니다. 그래도 문제는 이런 정황적인 상황으로 확신을 할 수 없기때문에 시놀로지가 직접 튜닝을 하던 안하던 골고루 분산되느냐, 어느정도 순차적으로 기록되느냐를 역시나 '알 수 없다.'라고 생각합니다. 이런 정황과 상관없이 '거의 가득 찬 상태에선 복불복이니 순차/비순차 유무는 상관없다.'이거나 LVM위에 파일시스템이 올라가는것이니 여기에서 오버헤드가 발생하여 더 느리므로 SHR을 안쓴다면 기록방식 부터 생각할 필요가 없겠지만요. 추가로 CIFS는 SMB같은 소프트웨어에서 OS의 파일스시템에 의해서 파일이 기록되는것이고 iSCSI는 씩프로비저닝/씬프로비저닝 상관없이 인식된 가상의 디스크 영역에서 파일을 쓰는 로직은 클라이언트의 파일시스템에 의존적이기때문에 파일 기록방식에서 시놀로지의 btrfs가 순차적으로 쓰느냐 아니냐와 다른 문제로 생각하는것입니다. 이상입니다.

​@@iruis 1. 댓글 삭제에 대한건 예전에 엄청 좋은 토론 내용이 있었는데, 저도 지운게 아니고 그분도 지우지 않으셨는데 없어진 경우가 있었습니다. 이게 한번이 아니라 몇번이 있었어요. 이번에도 그렇지 않기를 바래봅니다. 2. 가장 확실한 방법은 Synology에서 실제로 파일을 블럭에 어떻게 할당하는지 까 보면 된다고 생각합니다. 이때 가상머신은 제외해야 합니다. 가상머신들은 Sparse file system을 사용해서 실제와 다르게 보이는 부분이 있으니까요. 이걸 해 보려고 봤더니.. 시놀로지 CLI는 진짜 툴이 너무 없더군요. CentOS 설치해서 증명한다고 해도 이게 Synology 튜닝 여부 때문에 문제가 되구요. 결국 제 나스 더렵혀 가면서 컴파일러 깔고 직접 툴들을 컴파일 했습니다. Btrfs의 경우 스냅샷등등 다른 요인들이 파일 Allocation에 더욱더 영향을 줄 수 있기에 간단하게 SSD 하나 집어 넣고 (용량이 가장 작아야 테스트가 수월하다는 생각으로) 볼륨을 10GB만 잡았습니다. 그리고 1.txt 만들고 2.txt 만들어보니까 정확히 피지컬 블록이 붙어 있더군요. margin이 없었습니다. 여기서 1.txt가 블록 사이즈 즉 4096을 넘어가면 프레그멘테이션이 났습니다. 그리고 330매가짜리 파일만 딱 복사해서 3.pat 파일을 디스크 블럭으로 조회해보니 한 영역이 잘려서 저장되었습니다. 분명 한 파일이고 수정도 하지 않았는데 말이죠. 파일을 중간에 잘라서 마진을 줬더군요. 두 extends 간에 margin은 2049블록으로 약 8MB 였습니다. 그 다음으로 3948바이트 짜리 4.txt를 만들었고 이 파일을 그대로 복사해서 5.txt를 만들었습니다. 아까 그냥 0바이트 파일로 만들었던 1.txt, 2.txt가 연속 블럭으로 할당되었지만 4와 5는 연속 블럭이 아닌 505 블럭이 떨어진 곳에 만들어 졌습니다. margin을 사용했죠. 505블럭은 약 2MB 입니다. 즉 시놀로지는 파일을 배치할때 연속 블럭에 배치하지 않습니다. 3. 앞서 말씀 드렸지만, 저는 디스크 베이에 여유가 없습니다. 쓰던 디스크 하나 빼고 볼륨 삭제해가면서 SSD 넣어서 테스트 해 봤습니다. RAID도 아니었고, 기본에 ext4 였습니다. 제가 저번 답변에서 말씀드린 것 처럼 저 역시 SHR에서 어떨지 궁금합니다. 별 차이 없을것 같지만 한번 증명해 주시면 좋을 것 같습니다. 그럼 기술인으로서 제가 매우 행복할 것 같습니다. 이하는 제가 이해되지 않는 부분입니다. 이 부분도 기술인의 한사람으로서 너무 궁금합니다. 답변 해 주셨으면 좋겠습니다. 1. "시놀로지가 저장된 파일의 안전을 위해서 튜닝을 했다고 한다면, " 이라고 가장 첫 글에서 써 주셨는데요, 이 내용을 구체적으로 알고 싶습니다. 너무 궁금합니다. 2. iSCSI가 반드시 블럭 디바이스로 동작하나요? 즉 네트워크로 3000번 블럭에 데이터를 기록하라고 한다면, 실제로 피지컬 레이어에서 3000번 블록이나, N+3000번 블럭에 데이터를 기록하나요? 저는 아니라고 알고 있습니다. 따라서 iSCSI를 쓰든 말든 iSCSI 이미지를 최종적으로 저장한 파일 시스템에 따라 물리 볼륨에 저장될것으로 이해 됩니다. 이 부분 제가 잘못 알고 있다면 설명좀 부탁 드립니다. 3. 볼륨 축소할 때, 왜 빨리 되었을까요? 저도 이부분 궁금합니다. 원칙적으로 파일을 기록하는 속도와 파일을 삭제(0으로 기록)하는 속도는 같아야 하는데, 아시다 싶이 파일 삭제 할때 메타데이터만 싹 지우고 끝냅니다. 그래서 삭제 시간이 훨씬 짧죠. 같은 원리가 아닐까 추정 하는데, 관련 자료가 있을까요? 이하는 개인적으로 궁금한 부분입니다. 답변 안하셔도 됩니다. 1. ZFS도 쓰시고 데이터 규모가 크신거 같은데, SHR지금도 쓰고 계신가요? 이미 시놀로지 안쓰고 계신거 같은데... 구조가 궁금하네요. 이하 원본 댓글 입니다. -------------- @유랑인 만약 제가 댓글을 삭제한다면 삭제된 글의 댓글이 나타나는지를 모르겠군요. 암튼 댓글 내 링크가 있으면 큰 확률로 스팸처리 되는것같습니다. 덕분에 VMware의 이미지 포맷인 vmdk가 일정 용량으로 분할되어 있을 때 대다수 파일 확장이 이미지의 앞 번호 순서대로 확장되는걸 링크로 걸어드릴수도 없으니 아쉽군요. 저도 제 경험을 기반으로 뇌피셜로 풀자면, 꼭 디스크의 여러 부분에 분산되어 저장되지 않는다고 생각하는 부분으로 파티션 할당용량을 줄일 때 걸리는 시간때문입니다. 앞 문단과 같이 분할된 이미지의 앞 번호를 중점적으로 확장되는것도 있고, 윈도의 NTFS나 리눅스의 btrfs 용량을 백기가 이상, 수백기가 이상 많이 사용한 상태에서 파티션을 분할하기 위해, 또는 재배치를 위해서든 축소할 때 골고루 분할되어있다면 데이터를 앞으로 옮기기위해 그만큼 시간이 걸려야겠죠. 하지만 금방완료됩니다. (지금은 zfs로 이전하여 btrfs를 안쓰고있지만 LVM+btrfs로 머신의 파일시스템을 구측하여 사용할 때 확장 축소 여러번 해보았지만 영상때문에 몇테라씩 사용중이여도 축소 금방되었습니다.) 또한 최근에 100기가 정도밖에 사용하지 않는 가상머신의 디스크가 불필요하게 3테라 단일로 할당되어 파티션을 200기가로 줄이는데 몇분조차 걸리지 않았습니다. 그래도 문제는 이런 정황적인 상황으로 확신을 할 수 없기때문에 시놀로지가 직접 튜닝을 하던 안하던 골고루 분산되느냐, 어느정도 순차적으로 기록되느냐를 역시나 '알 수 없다.'라고 생각합니다. 이런 정황과 상관없이 '거의 가득 찬 상태에선 복불복이니 순차/비순차 유무는 상관없다.'이거나 LVM위에 파일시스템이 올라가는것이니 여기에서 오버헤드가 발생하여 더 느리므로 SHR을 안쓴다면 기록방식 부터 생각할 필요가 없겠지만요. 추가로 CIFS는 SMB같은 소프트웨어에서 OS의 파일스시템에 의해서 파일이 기록되는것이고 iSCSI는 씩프로비저닝/씬프로비저닝 상관없이 인식된 가상의 디스크 영역에서 파일을 쓰는 로직은 클라이언트의 파일시스템에 의존적이기때문에 파일 기록방식에서 시놀로지의 btrfs가 순차적으로 쓰느냐 아니냐와 다른 문제로 생각하는것입니다. 이상입니다.

SSD의 경우 피지컬 블럭 배치가 Cell의 수명에 따라 다를 수 있다고 여겨서 하드 넣어서 해 봤지만 비슷한 결과를 얻었습니다. 자잘한 파일 기준으로 연속 테스트를 해 보니 신기하게도 파일을 삭제한 후에 바로 생성한 파일의 경우 삭제한 블럭에 바로 기록하지는 않았지만, 시간이 흐르면 새 파일을 과거에 삭제했던 블럭을 재활용하기도 했습니다. 그리고 큰 파일은 왜 그런지 모르겠지만 일부로 조각 내는 경향도 있습니다. 테스트는 이제 그만하고 다시 풀 복구 중입니다.

@@Yurangin 1. 안전을 위해 튜닝은 2테라x2 + 3테라x2 구성시 앞 2테라 부분이 우선적으로 저장되도록 되어야 안정성이 더 높을테니 그렇게 되어있지 않겠느냐입니다. 하지만 테스트해보신대로 파일이 8메가 2메가 이런식으로 padding이든 margin이든 이루어 진다면 제가 지목했던 4:50 이런 상황이 연출되기 매우 힘들다고 판단됩니다. 제가 영상에서 지목한점이 디스크가 거의 가득차지 않는한 이런상황이 정말 발생하느냐입니다. 애초 데이터 저장을 저렇게 분산시키면 Read/Write 헤드가 그만큼 넓게 움직여야하는 상황이 많이 발생하게 되는데 과연 이득이 있을까요? 2. iSCSI는 일반 디스크처럼 섹터가 1:1로 매칭되는지 확인하는 가장 간단한 방법은 리눅스에서 tgtadm을 설치하고 fallocate -l 10G disk.img 등과 같이 대용량 파일을 생성하여 backing-store 지정 후 윈도에서 iSCSI 연결 후 디스크 초기화 하여 디스크를 가지고 논 후 리눅스에서 parted로 확인해보거나 partx -a disk.img 명령을 실행하면 하나의 디스크로 잘 인식되고 마운트됩니다. 애초 backing-store를 /dev/sda같이 물리 드라이브에 지정가능하고 사용 후 디스크를 데스크톱 PC에 연결해보면 iSCSI로 사용했을때와 동일하게 인식하여 사용할 수 있지만요. 3. 관련된 자료는 없습니다. 제 경험이라고 앞에 미리 설명드렸듯 단지 vmdk의 분할된 파일이 확장되는 상황, 축소가 매우 빠르게 되는등 정황상 앞쪽을 먼저 쓰지 않는한 발생할 수 없는 상황이라고 생각할 뿐입니다. 참고로 qemu-img convert multiple vmdk이라고 구글링하면 나오는 팁이지만 분할된 vmdk는 qemu-img로 각각 (disk-001.vmdk, disk-002.vmdk ...이런식이라면) qemu-img convert -f vmdk disk-001.vmdk -O raw disk-001.raw 등 각각 변환 후 concat 명령으로 합치면 그냥 하나의 디스크 이미지로 인식 가능합니다. (지금은 vmware를 사용하지 않고 libvirtd를 사용하고있기때문에 아쉽게도 직접 테스트를 못하고있지만요.) 즉 raw 디스크 이미지로 본다면 디스크의 앞 부분부터 기록된다입니다. 추가: 지금도 시놀로지 사용합니다. 거의 20년 가까이되는 자료들은 다 시놀로지 나스에 저장되어있으며 Hyper Backup을 구글 드라이브에 이중으로 백업할 수 있다는 장점때문에 zfs로 구성한 머신과 다른 이유로 계속 사용합니다. 디스크 장애가 발생하는 상황이 될때를 대비하여 시리얼 넘버별 어느 트레이에 디스크가 꼽혔는지 관리해야하고 그럼에도 직접 시리얼 넘버를 물리적으로 비교하면서 매우 주의하며 디스크를 교체해야하는 일반 PC와는 달리 장애가 발생한 베이 번호를 보고 교체하면 된다는 넘볼 수 없는 편리함도 있습니다.

RAID 5, Raid6 의 안정성이 더 높습니다.. 개인들은 2~3년 한 한번 정도는 날려 먹어도 별 문제 없지 않나요.. 하지만 회사는 절대 아니죠.. 회사 NAS 파일서버를 RAID 0 으로 잡으신 전산 관리자... 퇴사 당했습니다. .. 변명의 여지가 없죠..

댓글 수정을 방지 하기 위해서 미리 원본 글을 써 둡니다. --------- 뭐 이런 말도 안되는 영상을... 이 유랑인이라는 분은 JBOD가 뭔지도 모르나? 아니면 산수를 못하는건가? 이 영상 보시는 분들께 알려드립니다. 4TB + 8TB + 8TB면 각 디스크의 4TB부분만 묶어서 RAID5로 묶으니 8TB가 되고 나머지 두 디스크의 4TB 남는 영역은 이 영상에서처럼 JBOD로 묶는게 아니라 RAID1으로 묶는겁니다. 당연히 보호가 되는거고, 그래서 4TB가 추가되어 최종 12TB가 되는겁니다. 만약 유랑인의 주장대로 남은 4TB 부분을 JBOD로 묶으면 단순히 선형 결합(보호 안됨)이기 때문에 8TB가 되어 최종 용량은 16TB가 되어야 합니다. -------- 4 + 8 + 8 을 RAID5로만 묶으면 RAID는 용량 작은 디스크 기준으로 묶여야 하니 4+4+4로 같고, 8TB가 됩니다. 반면 SHR은 4+4+4로 8TB를 확보한 상태에서 남은 4+4를 한번더 RAID1로 묶고, 이 둘을 JBOD 하므로 8+4는 12입니다. 산수는 님이 못하신거 같은데.... www.synology.com/ko-kr/support/RAID_calculator?hdds=4%20TB|8%20TB|8%20TB 댓글 삭제 하시지 마세요. 혹시나 예전처럼 누가 댓글 삭제 할까봐 영상 녹화도 해 두었습니다.

댓글 수정을 확인해서 다시 남깁니다. 원본은 아래와 같습니다. -------------- 뭐 이런 말도 안되는 영상을... 이 유랑인이라는 분은 JBOD가 뭔지도 모르나? 아니면 산수를 못하는건가? 이 영상 보시는 분들께 알려드립니다. 4TB + 8TB + 8TB면 각 디스크의 4TB부분만 묶어서 RAID5로 묶으니 8TB가 되고 나머지 두 디스크의 4TB 남는 영역은 이 영상에서처럼 JBOD로 묶는게 아니라 RAID1으로 묶는겁니다. 당연히 보호가 되는거고, 그래서 4TB가 추가되어 최종 12TB가 되는겁니다. 만약 유랑인의 주장대로 남은 4TB 부분을 JBOD로 묶으면 단순히 선형 결합(보호 안됨)이기 때문에 8TB가 되어 최종 용량은 16TB가 되어야 합니다. 그리고 디스크의 용량이 서로 다른 상황은 당연히 과도기적인 성격이 강합니다. 순차적으로 용량을 증설하고 있는 상황이라고 보면 되겠죠. 항상 전부 같은 용량으로 RAID5나 6로 구성할 생각이면 당연히 SHR을 사용할 이유가 없습니다. 엔터프라이즈급에서는 당연히 이런 상황은 발생하지 않습니다. 언제나 최상의 성능을 유지하기 위해 전체 하드디스크의 교체를 원칙으로 하죠. 하지만 개인 이용자들에게 SHR은 정말 유용한 기능인겁니다. 유휴 디스크를 일단 장착하여 사용하면서 예산이 허락하는 시점에 하드디스크를 하나씩 증설해 나갈 수 있으니까요. SHR은 RAID와 같은 조건에서는 불리한 점이 없습니다. SHR 쓰시면 됩니다. 다만, 하드 디스크의 용량이 같아질 때 최고의 성능이 나오게 되니까 가급적 같은 용량으로 맞추는 노력만 하시면 됩니다. ------------- 영상의 0:35분 부터 스크립트를 그대로 따면 --------- 4TB 한장, 8TB 2장이 있다고 해 봅시다. 이를 RAID5로 묶는다면 가장 작은 용량인 4TB 3장으로 RAID5 하는 것과 같습니다. 따라서 총 사용가능한 용량은 8TB가 됩니다. 그런데 SHR은 여기서 한번 더 묶습니다. 남은 용량을 이렇게 RAID1로 묶는거죠. 그리고 RAID1과 RAID5를 JBOD로 합쳐 버립니다. 이렇게 하면 총 12TB를 쓸 수 있습니다. RAID5에 비하면 4TB를 더 쓸 수 있죠. --------- 영상에서도 분명 RAID1과 RAID5를 JBOD로 합친다고 했지, RAID1을 안하고 RAID5와 JBOD로 합친다고 하지는 않았습니다. 결국 난독..이 아니라 난청이라고 해야 하나요? 잘못 이해 하신것을 제가 잘못한거마냥 쓰셨는데, 뭐 잘못 이해할 수도 있다고 생각합니다. 그런데 그러면 "이 유랑인이라는 분은 JBOD가 뭔지도 모르나? 아니면 산수를 못하는건가?" 문장 보다는 정중하게 이야기 했어야 할 것입니다. 그리고 다음부분인 ------- 그리고 디스크의 용량이 서로 다른 상황은 당연히 과도기적인 성격이 강합니다. 순차적으로 용량을 증설하고 있는 상황이라고 보면 되겠죠. 항상 전부 같은 용량으로 RAID5나 6로 구성할 생각이면 당연히 SHR을 사용할 이유가 없습니다. 엔터프라이즈급에서는 당연히 이런 상황은 발생하지 않습니다. 언제나 최상의 성능을 유지하기 위해 전체 하드디스크의 교체를 원칙으로 하죠. 하지만 개인 이용자들에게 SHR은 정말 유용한 기능인겁니다. 유휴 디스크를 일단 장착하여 사용하면서 예산이 허락하는 시점에 하드디스크를 하나씩 증설해 나갈 수 있으니까요. SHR은 RAID와 같은 조건에서는 불리한 점이 없습니다. SHR 쓰시면 됩니다. 다만, 하드 디스크의 용량이 같아질 때 최고의 성능이 나오게 되니까 가급적 같은 용량으로 맞추는 노력만 하시면 됩니다. ------- 이 부분에 대해서는 영상에서도 이야기 하고 있는 상황입니다. 영상의 6:48 부분에서도 이야기 하고 있지만 용량을 택하면서 디스크 한장의 고장을 허용하는 안정적인 사용을 하고 싶다면 SHR을 택할수도 있습니다. 즉 개인의 선택 문제인 것이죠. 그래서 영상의 제목도 SHR을 "제가" 사용하지 않는 이유인 것 뿐입니다. 여러분들에게 SHR구리니까 RAID만 쓰세요라고 하지 않았으니까요. 근데 이걸 또 제가 "무조건 SHR을 쓰지 마세요" 라고 말하는 걸로 생각하셨던 것인지 위의 인용한 문장을 쓰신것 같습니다. 사실 저 내용 전부 이 영상에 있는 내용이며 "SHR은 RAID와 같은 조건에서는 불리한 점이 없습니다. SHR 쓰시면 됩니다." 역시 영상의 SHR 설명을 이해했다면, 당연히 모두가 아는 내용입니다. 영상에 있는 내용을 그저 요약하신 것인데, 뭐 영상을 대충보거나 띄엄띄엄 클릭해서 보시거나, 이해가 떨어지는 분들을 위한 요약이라고만 생각하겠습니다.

@@Yurangin 말씀하신대로 제가 난청이었군요. RAID5와 RAID1을JBOD로 묶는다고 설명하셨네요. 제가 실수했습니다. 좀 심하게 댓글을 단 부분 진심으로 사과드립니다. 아마도 건너뛰면서 봐서 JBOD로 묶는다는 말만 들었나봅니다. 어쩐지 뒤쪽은 오류 없이 설명이 이어진다 했을때 앞쪽을 다시 한 번 확인하지 않은 제 실수입니다. 제목을 보고 뭔가 SHR의 치명적인 문제점을 기대했는데 내용은 너무 당연한 내용이어서 제목 낚시질을 당했다는 느낌에 필요 이상으로 좀 과격하게 반응한 듯 합니다. 죄송합니다.

raid5로 묶은다음에 레이드1로 묶는게 아니라 jbod으로 묶습니다. raid1은 밥팔아 똥싸먹는 소리입니다. raid1은 A와 B가 독립된 디스크로 동작할때 효과있지.. 이미 raid5로 묶여서 같이 쓰고 있는 상황에서 동시에 다른부분에 raid5로 묶여 있는부분에 쓰면 오히려 속도가 더 떨어지게 됩니다. raid5로 묶고 다음에 jbod으로 묶는게 맞는거고 가장 효율적입니다.

@@artistminho 어떤 말씀을 하시고 싶으신건가요? 밥팔아 똥싸먹는 소리가 저는 무엇인지 이해하지 못했습니다. SHR은 모든 디스크 중에서 한장이 고장나도 버텨야 합니다. 즉 3개의 디스크로 RAID5를 할 수 있을땐 그렇게 하겠지만, 마지막 디스크 두장만 남은 상황에서는 RAID1을 한 후에 RAID5와 RAID1한 것을 JBOD로 묶습니다. 한장의 디스크 고장을 허용해야 하므로 만약에 디스크 한장에서만 남는 부분이 나온다면 해당 부분은 버려집니다. 이는 시놀로지 공식 홈페이지에서도 확인됩니다. 댓글 수정을 방지하기 위해 원본 댓글을 복사해 둡니다. ---------------------------------------------------------- raid5로 묶은다음에 레이드1로 묶는게 아니라 jbod으로 묶습니다. raid1은 밥팔아 똥싸먹는 소리입니다. raid1은 A와 B가 독립된 디스크로 동작할때 효과있지.. 이미 raid5로 묶여서 같이 쓰고 있는 상황에서 동시에 다른부분에 raid5로 묶여 있는부분에 쓰면 오히려 속도가 더 떨어지게 됩니다. raid5로 묶고 다음에 jbod으로 묶는게 맞는거고 가장 효율적입니다. ----------------------------------------------------------

가정인데 SMB 멀티채널 해 놓고 속도 안나와, 10Gbps 구축해 놓고 속도 안나와 하는 이야기들이 많습니다. 당연히 고대역이 필요한 사람들도 있고 그런 사람들은 속도가 출렁거리는 현상 (디스크 처리 갯수가 왔다갔다 하므로)을 싫어하거나, 성능에 못 미친다고 이야기 합니다. 본인처럼 단순한 환경인 곳도 있지만 그렇지 않은 곳도 있습니다. 가정에서 그냥 SHR 쓰면 됨 이라고 의견 내신것은 좋으나 쌉소리하네는 당신의 밑천을 드러낸 것이라고 생각합니다. 수준 잘봤습니다. 원본 댓글 가정에선 그냥 SHR 쓰면 됨. 혼자 쌉소리 하네...

영상 후반부에 SHR을 백업용도(데이터 저장 용도)로 사용하기에 좋다고 설명하고 있습니다. 영상을 어떻게 이해하셨길레, 또는 제가 영상을 너무 어렵게 만들었는지 모르겠지만 영상에서는 SHR의 장점(확장성 용이) 단점 (5개 구성할때 1번 디스크의 용량이 꽉 차면 4개의 디스크로 분산 되므로 성능이 20% 떨어지는 문제, 용량 더 차서 2개 차면 40% 떨어지는 문제)를 언급하고 있습니다. 즉 필요에 따라 판단해서 쓰라고 한건데 이게 뻘소리 인가요? 그리고 어차피 이거 보는 사람들 다 가정용이라... 질문에 아닌 것들도 참 많았습니다. 영상 편집하는데 10기가 망을 구성해야 하는지 같은 질문들요. 무조건 본인의 시야로 보지 마시기 바랍니다. 제 눈엔 이게 더 뻘소리로 보입니다. 수정 대비 제가 본 댓글 영상 캡쳐하고 적어 둡니다. -------- 어차피 이거 보는 사람들 다 가정용인데 SHR 써도 문제 없습니다. 성능 저하 무시해도 됨. 전혀 지장없을 수준임. 괜히 이 영상의 뻘소리에 의미부여 마시길...