야간 라이브러리 스캔으로 하드 드라이브가 계속 깨어나는 문제를 줄이는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Overnight Library Scans Keep Waking Hard Drives: How to Reduce Them

미디어에 접근하는 정확한 예약 작업을 찾아 빈도, 범위 또는 파일 수준 작업을 제한하면 밤새 드라이브가 깨어나는 횟수를 줄일 수 있습니다.

데이터베이스와 캐시가 SSD에 있어도 미디어 서버는 절전 상태의 HDD를 깨울 수 있습니다. 예약된 라이브러리 스캔이 디렉터리를 순회하거나, 파일을 검사하거나, 아트워크를 새로 고치거나, 미리보기를 생성하거나, 경로를 확인하거나, 안정적인 상태에 도달하지 못한 항목을 처리할 수 있기 때문입니다. 먼저 첫 디스크 접근을 하나의 작업 및 하나의 로그 항목과 연결하세요. 트리거를 입증하기 전에 스핀다운 타이머를 변경하면 근본적인 읽기를 줄이지 못한 채 패턴만 숨길 수 있습니다.

드라이브를 깨우는 예약 작업 입증하기

디스크 모니터링, 시스템 로그 또는 전력 모니터링에서 정확한 깨움 시간을 기록한 다음, 미디어 서버의 예약 작업 기록과 비교하세요. 결과를 특정 작업의 영향으로 판단할 수 있도록 의심되는 작업 하나만 하룻밤 비활성화하세요.

한 Jellyfin 보고서에서는 예약된 라이브러리 스캔이 하루에 두 번 전체 라이브러리를 반복 처리하고 미디어 검사에 몇 시간씩 걸리는 것으로 나타났습니다. 유용한 단서는 일회성 재생 요청이 아니라 동일한 전체 스캔이 계속 반복되었다는 점이었습니다.

라이브러리 스캔이 시작되기 전에 드라이브가 깨어난다면 챕터 이미지 추출, 트릭플레이 생성, 인트로 분석, 메타데이터 새로 고침, 백업, SMART 테스트, 파일 시스템 스크럽 또는 다운로드 정리 작업과 같은 다른 작업을 확인하세요. 첫 접근 증거에 해당 프로세스나 컨테이너가 나타나기 전까지는 미디어 서버를 원인으로 단정하지 마세요.

전체 라이브러리 스캔과 실시간 모니터링 구분하기

라이브러리가 주기적인 전체 스캔과 파일 시스템 모니터링을 모두 사용하는지 확인하세요. 지원되는 로컬 파일 시스템에서는 실시간 모니터링으로 일반적인 추가 항목을 빠르게 가져올 수 있으며, 예약된 전체 스캔은 더 낮은 빈도의 안전망으로 활용할 수 있습니다.

Jellyfin은 오래전부터 예약 스캔과 실시간 모니터링을 별도의 메커니즘으로 취급해 왔습니다. 프로젝트 이슈에 따르면 실시간 모니터링은 새 미디어를 감지할 수 있고 예약 작업은 일정 간격으로 항목을 검색합니다.

신뢰할 수 있는 로컬 저장소에서는 새로 추가한 파일 하나로 실시간 모니터링을 테스트하고, 해당 파일이 정상적으로 표시된 후에만 전체 스캔 빈도를 줄이세요. NFS, SMB, rclone, 병합 파일 시스템 및 일부 컨테이너 마운트 경로에서는 이벤트 전달이 불완전할 수 있으므로 저장소 정책에 맞는 시간에 주기적인 스캔을 유지하세요.

디렉터리 이름만이 아니라 미디어 내용을 읽는 작업 찾기

스캐너 로그에서 미디어 검사, 체크섬 읽기, 챕터 추출, 자막 분석, 트릭플레이 생성, 음량 분석 및 반복되는 메타데이터 새로 고침을 확인하세요. 디렉터리 열거는 잠깐 드라이브를 깨울 수 있지만, 모든 파일의 일부를 읽으면 전체 어레이가 몇 시간 동안 활성 상태로 유지될 수 있습니다.

앞서 언급한 반복 스캔 사례에서는 검사 중 각 미디어 파일에서 상당한 양의 데이터를 읽는 것으로 보고되었습니다. 이는 해당 작업이 파일 이름만 확인한 것이 아님을 설명합니다. 또 다른 이슈에서는 동일한 항목이 모든 스캔에서 다시 처리되는 현상이 안정적인 상태에 도달하지 못한 채 반복되었습니다.

실행할 때마다 변경되는 첫 번째 항목을 수정하세요. 사용할 수 없는 경로, 권한 오류, 잘못된 사이드카 파일, 불안정한 타임스탬프, 중복 라이브러리 루트 또는 반복적으로 삭제되고 다시 생성되는 메타데이터 레코드가 원인일 수 있습니다. 각 스캔이 여전히 동일한 콘텐츠를 새 항목으로 처리한다면 스케줄을 더 짧게 설정해도 도움이 되지 않습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

메타데이터를 SSD에 보관하되 모든 깨움이 멈춘다고 단정하지 않기

플랫폼에서 지원한다면 애플리케이션 데이터베이스, 캐시, 포스터 및 활성 메타데이터를 SSD에 배치하세요. 이렇게 하면 탐색 중 소규모 랜덤 읽기를 줄이고 일반적인 데이터베이스 유지 관리 작업을 대용량 디스크에서 분리할 수 있습니다.

하지만 저장소를 분리해도 모든 문제가 해결되는 것은 아닙니다. Jellyfin 회귀 보고서에서는 캐시와 메타데이터가 NVMe에 있어도 라이브러리 세부 정보를 확인할 때 HDD가 깨어난 사례가 확인되었습니다. 이는 일부 작업에서 서버가 소스 미디어에 여전히 접근할 수 있음을 보여줍니다.

애플리케이션 데이터를 옮긴 후 탐색 및 스캔 중 어떤 소스 경로가 열리는지 확인하세요. 가능하면 포스터, 미리보기 및 데이터베이스를 미디어 디스크에서 분리하되, 남아 있는 소스 파일 접근은 SSD 이전이 실패했다는 증거가 아니라 별도로 진단해야 할 동작으로 취급하세요.

빈도, 범위 및 겹치는 작업 줄이기

라이브러리에 필요한 만큼만 전체 스캔을 실행하고, 백업, 스크럽, 미리보기 생성 또는 미디어 가져오기와 같은 작업과 동시에 예약하지 마세요. 플랫폼에서 대상 새로 고침을 지원한다면 개별 라이브러리나 폴더만 스캔하세요.

메타데이터를 실제로 다시 만들어야 하는 경우가 아니라면 일반적인 스캔에서 광범위한 메타데이터 교체를 비활성화하세요. 정상적인 증분 스캔에서는 변경되지 않은 미디어의 챕터 이미지, 트릭플레이 파일, 포스터 및 에피소드 식별 정보를 반복적으로 다시 생성해서는 안 됩니다.

가져오기를 먼저 실행하고, 가져오기 시간대가 끝난 후 대상 라이브러리를 새로 고치며, 대용량 파생 작업은 별도의 날에 실행하거나 필요할 때만 실행하도록 일정을 분산하세요. 이렇게 하면 밤새 여러 번 짧게 깨어나는 대신 예측 가능한 하나의 활성 시간대가 만들어집니다.

미디어 서비스 시작 전에 마운트 사용 가능 여부 확인하기

네트워크 마운트나 풀링된 마운트가 사라지면 예상 경로에 빈 로컬 디렉터리가 나타날 수 있습니다. 미디어 서버가 이 대체 경로를 스캔해 항목을 삭제한 후, 실제 공유 폴더가 돌아오면 모든 항목을 다시 스캔할 수 있습니다.

드라이브 또는 마운트가 중단되면 미디어 라이브러리가 사라지고 비용이 큰 재구성이 강제될 수 있습니다. Jellyfin 이슈에서는 마운트 연결 해제 후 라이브러리가 손실된 사례가 설명되어 있으며, 시작 종속성으로 방지해야 하는 장애 유형입니다.

필수 마운트가 활성화되고 콘텐츠가 준비된 후 컨테이너나 서비스가 시작되도록 구성하세요. 알려진 마커나 예상 파일 시스템 유형을 확인하는 마운트 존재 여부 검사를 추가한 다음, 저장소 경로를 사용할 수 없을 때는 스캔을 중지하세요. 빈 디렉터리를 유효한 라이브러리로 처리해서는 안 됩니다.