SataPortMap 과 DiskIdxMap 설정이 과연 필요한지에 대한 또한번의 고찰

DS920+, DS1621+등의 Device Tree 기반이 아닌 Non-DT 모델의 레드필 로더를 빌드하시면서 

다들 한번씩은 고민하고 고생을 해보신 SataPortMap 과 DiskIdxMap 에 대해 한번 다시 짚고 넘어가고 싶습니다.

TCRP가 처음 릴리즈 되었을때 부터 아래 satamap action으로

./rploader.sh satamap now 

로 SataPortMap 과 DiskIdxMap 는 필수로 설정을 해야 하는것처럼 굳어져 버렸습니다.

하지만, pocopico님의 rploader.sh 소스의 내용중 satamap() 함수를 따라가 보시면 맨 상단에 아래처럼

지침사항이 있습니다.

"ThorGroup은 컨트롤러 포트를 매핑하지 말라"고 조언 했습니다.

Maxdisks 제한을 초과할 만큼 많은 디스크를 장착해야 하는 경우라면 얘기가 좀 다르지만

그 이내의 경우라면 포트매핑은 필수 사항이 아니라는 얘기입니다.

그래서, 최근 이 SataPortMap 과 DiskIdxMap 를 잘못 설정하셔서 디스크를 찾지 못하거나 에러나 가는 경우는 아래처럼 값을 아예 비워서 사용해 보라고 가이드를 합니다.

m shell 에서는 최근에 VM인 경우는 자동으로 저렇게 셋팅을 해주고 있습니다.

"SataPortMap": "",
"DiskIdxMap": ""

일단 최초 시도는 ThorGroup의 지침대로 따르고 그래도 문제가 발생시에는 저 값들을 조정해 가는게 맞는게 아닌가 싶습니다.

저도 모든 케이스를 다 고려해서 테스트를 해보진 못했지만, 이 지침을 우선 적용해서 사용해 본 이후

안되는 경우 SataMap Action을 적용해서 케이스를 도출해 볼 생각입니다.

사용자 분들도 처음엔 저 값을 비워서 성공여부, 안됬을경우 다시 SataPortMap 과 DiskIdxMap 셋팅을 해서 성공여부

등을 공유해 주시면 어떤 하드웨어 (VM 포함) 가 사용되는 케이스에서 예외가 발생하는지 케이스 집계를 해보는 방법도 좋을것 같습니다.

--------------------------------------------------------------------------------------------------------------------------------

This function identifies all SATA controllers and create a plausible sataportmap and diskidxmap.

In the case of SATABOOT: While TinyCore suppresses the /dev/sd device servicing synoboot, the

controller still takes up a sataportmap entry. ThorGroup advised not to map the controller ports

beyond the MaxDisks limit, but there is no harm in doing so - unless additional devices are

connected along with SATABOOT. This will create a gap/empty first slot.

By mapping the SATABOOT controller ports beyond MaxDisks like Jun loader, it forces data disks

onto a secondary controller, and it's clear what the SATABOOT controller and device are being

used for. The KVM q35 bogus controller is mapped in the same manner.

DUMMY ports (flagged by kernel as empty/non-functional, usually because hotplug is supported and

not enabled, and no disk is attached are detected and alerted. Any DUMMY port visible to the

DSM installer will result in a "SATA port disabled" message.

SCSI/SAS and non-AHCI compliant SATA are unaffected by sataportmap and diskidxmap but a summary

controller and drive report is provided in order to avoid user distress.

This code was written with the intention of reusing the detection strategy for device tree

creation, and the two functions could easily be integrated if desired.

-> 구글 한국어 번역

이 기능은 모든 SATA 컨트롤러를 식별하고 그럴듯한 sataportmap 및 diskidxmap을 생성합니다.

SATABOOT의 경우: TinyCore가 synoboot를 서비스하는 /dev/sd 장치를 억제하는 동안

컨트롤러는 여전히 sataportmap 항목을 차지합니다. ThorGroup은 컨트롤러 포트를 매핑하지 말라고 조언했습니다.

MaxDisks 제한을 초과하지만 추가 장치가 없는 한 그렇게 하는 데 아무런 해가 없습니다.

SATABOOT와 함께 연결됩니다. 이렇게 하면 간격/빈 첫 번째 슬롯이 생성됩니다.

Jun 로더와 같은 MaxDisk를 넘어 SATABOOT 컨트롤러 포트를 매핑하여 데이터 디스크를 강제 실행합니다.

보조 컨트롤러에 연결하고 SATABOOT 컨트롤러와 장치가 무엇인지 명확합니다.

사용. KVM q35 가짜 컨트롤러도 같은 방식으로 매핑됩니다.

DUMMY 포트(보통 핫플러그가 지원되고

활성화되지 않았으며 연결된 디스크가 없음을 감지하고 경고합니다. 볼 수 있는 모든 DUMMY 포트

DSM 설치 프로그램은 "SATA 포트 비활성화됨" 메시지를 표시합니다.

SCSI/SAS 및 비 AHCI 호환 SATA는 sataportmap 및 diskidxmap의 영향을 받지 않지만 요약

사용자의 고통을 피하기 위해 컨트롤러 및 드라이브 보고서가 제공됩니다.

이 코드는 디바이스 트리에 대한 탐지 전략을 재사용할 의도로 작성되었습니다.

생성하고 원하는 경우 두 기능을 쉽게 통합할 수 있습니다.